Ai cũng nghĩ 'chỉ đếm thôi' thì nhẹ hơn 'in đầy đủ'. Đo thật: strace -c chậm 446 lần, bản in đầy đủ 501 lần — chênh vỏn vẹn 12%, vì tiền không đi vào chỗ bạn tưởng. Mà trên chương trình không gọi hệ thống thì strace lại miễn phí. Chi phí tính theo số lời gọi, không theo thời gian chạy.
strace làm chậm 446 lần vì nó chặn từng lời gọi. perf đứng ở đầu kia của thang: nó chỉ thỉnh thoảng ngắt ra ghi con trỏ lệnh đang ở đâu, rồi đếm — chi phí không đo được, mà bốn hàm vẫn xếp hạng đúng tới 0,15 điểm phần trăm. Cùng logic thăm dò ý kiến: đủ mẫu ngẫu nhiên là tỷ lệ hội tụ về sự thật.
Một con số đúng vẫn có thể chẳng giúp được gì. Hồ sơ phẳng bảo toàn bộ CPU nằm trong một hàm tiện ích gọi từ khắp nơi — biết tên mà không biết ai gọi. Tách cùng số liệu ấy theo ngăn xếp: nén ngốn 85%, và một hàm nen() hiện ra hai lần với hai tỷ lệ khác nhau tuỳ ai gọi nó.
strace muốn nhìn phải dừng tiến trình rồi đọc thanh ghi từ bên ngoài — chậm 446 lần. eBPF nạp thẳng chương trình đo vào trong nhân, chạy tại chỗ. Kết quả: 2 lần chi phí, thấy cả máy trong một lần đo, và một cái đuôi 128–256 micro giây mà không trung bình hay phân vị nào bắt được.
Ghi log nằm trên đường đi của mọi yêu cầu. Tôi đo sáu cách ghi cùng một dòng: định dạng chuỗi tốn 0,052 µs, còn fsync mỗi dòng tốn 515,903 µs — chi phí không nằm ở chỗ ai cũng tối ưu (định dạng) mà ở mỗi lần dữ liệu *ra khỏi tiến trình*. Kèm cái bẫy đắt nhất: một log.debug đã tắt vẫn dựng chuỗi trước khi bị bỏ, tốn 62 lần so với truyền tham số rời.
Lấy giờ là thứ mọi log, mọi số liệu, mọi phép đo đều làm. Tôi đo chín cách và tìm ra chênh lệch 11 lần giữa hai cách gọi cùng một hàm (vDSO hay không), một biến thể COARSE rẻ 6 lần đổi lấy độ phân giải 1 ms, và một hàm — clock_getres — báo sai độ phân giải thật tới 24.000 lần. Kèm lỗi kinh điển: dùng REALTIME cho thời hạn.