Mỗi syscall dưới strace tốn ~80 micro giây thay vì 126 nano giây — chậm 630 lần. Nghĩa là mọi con số thời gian đo được khi strace đang bám đều sai bét. Chính cái thước tin cậy nhất của tôi lại là hiệu ứng người quan sát ở dạng thuần khiết nhất. Đo thật, và một maxim của sê-ri bị lật ngược.
ORDER BY trên 1 triệu hàng: work_mem nhỏ thì external merge tràn đĩa 208ms, lớn thì quicksort RAM 162ms. Nhưng ORDER BY LIMIT 10 dùng top-N heapsort chỉ 25kB, 53ms — không sắp hết. Đừng đoán thuật toán từ câu SQL; EXPLAIN cho biết cơ sở dữ liệu thật sự sắp thế nào, và một index có thể bỏ luôn bước sắp.
Đọc mã nguồn cả ngày cũng không thấy tranh chấp: hai luồng, hai biến riêng, không đụng nhau. Vậy mà chậm ~3,7 lần chỉ vì hai biến tình cờ nằm chung một cache line. Nút thắt vô hình ở tầng mã nguồn, chỉ lộ khi nhìn xuống bố trí bộ nhớ. Đo thật, và cách săn nó.
Con trỏ hàm với std::function bị mang tiếng là chậm vì gọi gián tiếp. Nhưng đo ra, khi đích ổn định — kể cả một mẫu lặp đều đặn — nó nhanh gần bằng gọi thẳng. Chỉ khi đích nhảy loạn khó đoán mới chậm gấp 6 lần. Cái quyết định không phải bản thân cú gọi gián tiếp, mà là CPU có đoán nổi bạn sắp gọi ai.
Tưởng đo NUMA được ở mọi máy nhiều lõi, và thêm luồng thì băng thông bộ nhớ tăng tuyến tính? Máy đo chỉ 1 node nên không có NUMA để đo — tôi báo trung thực chứ không bịa số. Nhưng cục bộ thì đo được và khổng lồ: đọc tuần tự nhanh hơn ngẫu nhiên 405 lần, băng thông chung chỉ scale 5,4 lần, chia dữ liệu gần luồng nhanh hơn rải 3,3 lần.
Tưởng một cấu trúc chung với một khóa là đủ, hoặc càng nhiều shard càng tốt? Tôi đo: một khóa chung sụp từ 229 xuống 35,7 triệu op/s khi đông luồng, chia nhiều shard giúp throughput scale 3 lần — nhưng càng nhiều shard, tính tổng toàn cục càng đắt (65 nghìn shard mất 32,8µs). Sharding dời chi phí chứ không xóa.