Nhìn thì memcpy chỉ là chép một dãy byte, viết tay bằng vòng for cũng ra thế. Nhưng đo ra memcpy nhanh gấp 15 lần cái vòng đó, và tốc độ của nó còn nhảy múa gấp 40 lần tùy khối to hay nhỏ. Một hàm tưởng tầm thường mà giấu cả một đường cong hiệu năng.
Tưởng throughput cao là hệ nhanh, và đo latency bằng trung bình là đủ? Tôi đo từng thao tác dưới tranh chấp: throughput và latency là hai thứ khác nhau có thể cùng tệ đi, và latency là một phân phối lệch — ở 8 luồng trung vị chỉ 125ns nhưng p99 vọt lên 32.292ns, gấp 258 lần. Trung bình giấu cái đuôi mà người dùng thật sự gặp.
Tin lời khuyên kinh điển 'subquery chậm, viết lại thành JOIN'. Đo ngược: IN và EXISTS ra kế hoạch y hệt (semi join), và semi join đó nhanh gấp 10 lần JOIN+DISTINCT của tôi — vì DISTINCT nối cả triệu cặp rồi mới khử trùng. Nhãn 'subquery hay join' gần như không quyết định tốc độ; cái quyết định là việc truy vấn thật sự cần làm, đọc được trong EXPLAIN.
Bung vòng lặp (unroll) luôn làm code nhanh hơn vì cắt chi phí vòng? Đo trên host ARM: bung một vòng cộng mảng 1x/2x/4x/8x với một biến tích lũy cho thời gian y hệt nhau — 0,2136 ns mỗi phần tử, không đổi, vì lõi out-of-order đã giấu hết chi phí vòng. Cái thật sự giúp là phá chuỗi phụ thuộc bằng nhiều biến độc lập (3,5 lần), còn khi memory-bound thì unroll vô ích. Và -O3 tự vector hóa còn nhanh hơn bung tay.
Merge join trên khóa đã sắp: 77ms không cần sort; nhưng trên cột chưa sắp phải thêm Sort tràn đĩa, 160ms (hash chỉ 78ms). Tôi suýt kết luận 'merge dở hơn hash' — cho tới khi thấy mình đo nó ở đúng điều kiện bất lợi. Đổi lại nó giữ nguyên thứ tự: ORDER BY LIMIT nhanh 0,03ms so với 72ms của hash.
Bài kết sê-ri: cùng một bài toán 'x có trong tập không', kẻ thắng đổi theo quy mô — quét tuyến tính nhanh nhất ở n=8, hash ở n lớn, bitset đè bẹp cả nếu biết miền khóa; và nhị phân O(log n) luôn kẹt giữa, không bao giờ nhanh nhất. Không có cấu trúc tốt nhất phổ quát — đo, đừng đoán.