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ó.
Đọc /proc/self/stat tốn ~1,5 us, tôi suýt khái quát 'mọi file /proc đều rẻ vậy'. Nhưng smaps tốn 12 us và còn phình theo bộ nhớ tiến trình, vì nhân phải đi bộ toàn bộ bảng trang. Cái rẻ và cái đắt nằm chung một thư mục trông y hệt nhau. Đo thật.
Ai cũng tin 'load average = mức bận CPU'. Nhưng trên Linux nó đếm cả tiến trình kẹt chờ I/O — 4 tiến trình chờ đĩa đẩy load lên 4 dù CPU nhàn tênh. Cùng con số load 8, hai căn bệnh trái ngược. Và nó còn dâng chậm vì làm mượt. Đo thật hai lầm tưởng của chính tôi.