mmap trông như miễn phí vì không có syscall read — phép đo đầu cho nó nhanh gấp 8 lần. Nhưng getrusage tố cáo nó mới chạm 2176 trang chứ chưa đọc hết file. Cho cả hai cùng cộng 256MB: read() nhanh gấp 5 lần mmap (87 so với 430 ms). Benchmark chỉ có nghĩa khi hai bên làm đúng cùng một việc.
Hàm to gọi từ một chỗ vẫn được nội tuyến bất kể lớn; gọi từ nhiều chỗ thì gcc giữ lời gọi. Tôi ép always_inline vượt ngưỡng — đổi 14 lần kích thước mã lấy vỏn vẹn 1% tốc độ. Đo bằng objdump thật trong container.
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.
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.
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.