Là một lập trình viên yêu công nghệ, thích viết blog để chia sẻ kiến thức, kinh nghiệm lập trình và những điều thú vị trong thế giới tech.
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 nanosleep(1µs) ngủ đúng 1µs? Tôi đo: yêu cầu 1µs thực ngủ 15,8µs (gấp 16 lần!), 10µs thành 60µs — có một cái sàn ~15µs vì đánh thức một luồng là cả một lần lập lịch lại. Ngủ ≥100µs mới sát; muốn trễ dưới µs phải busy-spin, đốt CPU.
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.
write() một khối 512 byte tốn 0,39µs; thêm fdatasync thành 518µs — gấp 1312 lần trên overlayfs, nhưng chỉ 4,2 lần trên FUSE. Tỉ lệ khác nhau là vì write baseline khác nhau, không phải fsync bất thường. Và write() trả về thành công KHÔNG bảo đảm dữ liệu đã bền — chỉ fsync mới.
Văn bản co lại 88-95% nhờ nén, gần như miễn phí. Nhưng nén dữ liệu ngẫu nhiên (ảnh, video đã nén) chỉ phình thêm byte, và nén payload tí xíu còn to hơn bản gốc. Cộng thêm một phép so gzip-vs-Brotli thiếu công bằng suýt lừa tôi. Đo thật cả hai bộ nén ở nhiều mứ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.