Ai cũng dặn phải căn lề dữ liệu kẻo truy cập bộ nhớ chậm. Nhưng đo trên ARM, đọc lệch — kể cả cắt ngang dòng cache — nhanh y hệt căn lề. Chỉ có đúng một chỗ khiến nó lết: khi 8 byte vắt qua ranh giới trang, chậm gần 30 lần. Cái x86 bắt bạn sợ với cái thật sự nguy hiểm hóa ra không phải một.
AVL sửa cây tìm kiếm suy biến: cùng khóa đã sắp, chiều cao 40000 xuống 16, tra 32538 ns xuống 215 ns. Nhưng trên khóa ngẫu nhiên AVL hơn không đáng kể mà tốn 27906 phép xoay — cân bằng là bảo hiểm cho ca xấu, không phải quà miễn phí. Và cùng cây cân bằng, bố cục bộ nhớ làm tra chênh 6 lần. Tôi đo.
Round-robin chia đều tăm tắp theo lượt, kể cả nhét 20 request cho backend chậm nhất. Least-connections thì chỉ đưa nó 2 request, dồn phần còn lại cho hai máy rảnh. 'Đều' không phải 'cân bằng' — và cái khác biệt đó quyết định 1/N người dùng của bạn có phải chờ máy ốm hay không. Đo thật bằng nginx.
Muốn một cấu trúc có thứ tự với tra cứu O(log n) thì bắt buộc phải cây cân bằng với logic xoay rắc rối? Đo ra: skip list đạt O(log n) kỳ vọng chỉ bằng tung đồng xu — chèn không xoay, code đơn giản hơn nhiều, chậm hơn std::map chỉ 8–12%. Nhưng nó không phải luôn thắng: cây đỏ-đen tối ưu kỹ vẫn nhanh hơn ở đơn luồng, và O(log n) của skip list chỉ là kỳ vọng.
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.
Ai cũng bảo đặt điều kiện rẻ, hay-sai lên trước để && dừng sớm né phép đắt thì nhanh hơn. Tôi đo và hiệu năng đi ngược: bản bitwise & không nhánh, tính cả hai mọi lần, lại nhanh nhất. Hóa ra giá trị thật của && không phải tốc độ, mà là ngữ nghĩa bảo vệ null — thứ mà đổi sang & là làm crash.