Mang niềm tin cũ 'CTE là hàng rào tối ưu, luôn chậm hơn subquery', tôi viết CTE thường rồi ngồi đợi nó chậm. Đo ra nhanh y hệt subquery — 0,134ms, index scan — vì từ PG12 CTE được inline. Chỉ khi ép AS MATERIALIZED thì hàng rào cũ mới trở lại: 95ms, chậm 720 lần cho cùng logic. Vì sao một luật hiệu năng hết hạn theo phiên bản.
Tưởng select, poll, epoll như nhau chỉ khác cú pháp API? Tôi đo: select/poll là O(N) — quét cả danh sách fd mỗi lần, poll bung từ 1,9µs (100 fd) lên 203µs (10.000 fd); epoll O(1) phẳng ~130ns bất kể N, nhanh gấp 1.540 lần ở 10.000 fd. Bề mặt giống nhau, độ phức tạp thì không.
Tưởng speedup = thời gian 1 luồng / N luồng là đủ, và scaling tuyến tính tới số lõi? Tôi đo: 10 lõi chỉ cho 4,65x (không phải 10x), và nếu lấy baseline sai (bản song song 1 luồng thay vì tuần tự tốt nhất) thì con số bị thổi phồng đều 6,2 lần. Speedup là một phân số, và mẫu số nào cũng nói dối được.
Tưởng lock-free luôn nhanh hơn có khóa nên cứ bỏ mutex đi? Tôi đo: hàng đợi SPSC lock-free nhanh hơn mutex 3 lần vì hai bên ghi hai chỉ số riêng không tranh; nhưng nhiều producer cùng đẩy vào một hàng đợi thì ở 8 producer lock-free lại thua mutex, vì đụng đúng bức tường cache. Lock-free nhanh khi không có ghi chung, và cái giá là code khó viết đúng.
Tưởng chia đều số phần tử cho mỗi lõi là cân bằng tải? Tôi đo: khi mỗi phần tử tốn khác nhau, chia khối làm một luồng thành kẻ tụt hậu (lệch 21,7 lần), tổng thời gian kẹt ở luồng chậm nhất chứ không phải trung bình; chia xen kẽ san đều gần miễn phí. Và một cái rào ngầm suýt che mất toàn bộ hiện tượng khi tôi đo.
Tám luồng bận không ghim: nhân tự trải ra tám lõi khác nhau, 854.562 đơn vị công việc. Ghim hết vào một lõi tưởng 'kiểm soát tốt' nhưng chỉ được 165.906 — bằng 1/5, chín lõi ngồi không. Affinity tốt cho một luồng nóng nhưng phản tác dụng khi gom nhiều luồng song song.