Theo dõi 10.000 fd: poll tốn ~248 micro giây mỗi lần gọi, epoll chỉ ~130 nano giây. Tôi định chốt 'epoll là O(1)'. Rồi tôi tăng số fd sẵn sàng và nó lộ ra là O(số fd sẵn sàng), không phải hằng số. Ưu thế thật của epoll đến từ một giả định về tải. Đo thật.
O_DIRECT bỏ qua page cache, nghe như tối ưu. Nhưng đọc lại từ cache buffered ấm nhanh gấp ~5 lần. O_DIRECT là I/O KHÔNG cache, không phải I/O nhanh. Và lần đo đầu trên bind-mount cho kết quả vô lý vì các tầng cache lồng nhau nuốt luôn cờ direct. Đo thật.
sendfile gộp cả file 512 MB vào ĐÚNG 1 lời gọi thay vì 16.384 read+write. Nhưng trên loopback cache ấm, tốc độ thô của nó còn thua read+write đệm 64K — và tôi suýt kết luận nó vô dụng. Lỗi nằm ở chỗ tôi đo thông lượng, trong khi sendfile thắng ở CPU/syscall. Đo thật.
Ai cũng biết cấp phát stack nhanh hơn malloc, nhưng phép đo đầu của tôi cho hai bên bằng nhau — dấu hiệu đo sai. Sửa lại: stack ~1 ns cho MỌI kích cỡ, malloc chậm 6-14 lần. Đổi lại stack giới hạn 8MB, tràn thì crash không báo; heap trả NULL. Đo thật.
Ép malloc về một arena chỉ làm 8 luồng chậm từ 556 xuống 434 triệu op/s — tưởng arena vô dụng. Nhưng có một biến ẩn đang gánh thay nó: tắt luôn tcache thì thông lượng sập còn 23. Hai lớp chống tranh khóa, mỗi lớp che hiệu ứng của lớp kia. Đo thật.
Đọ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ó.