Microbenchmark báo 0,9 ns mỗi phần tử, lên production chậm gấp trăm lần — code không sai, dữ liệu đã đổi cỡ. Đo trên host ARM: cùng một thao tác O(n) đuổi con trỏ, 0,91 ns khi vừa L1, 104 ns khi ra RAM — chênh 114 lần. Vẽ ns/phần tử theo working set ra một đường bậc thang, và 'O(n) là tuyến tính' hóa ra chỉ đúng trong một tầng cache.
Trực giác bảo lệnh đọc phải đợi lệnh ghi xuống cache. Đo trên host ARM thì không: store buffer chuyền thẳng giá trị vừa ghi, ghi-đọc khớp chỉ 1,55 ns (~7 chu kỳ). Nhưng cái 'store-forwarding stall' mà dân x86 sợ chết khiếp, ở đây chỉ đắt thêm 18%. Thứ thật sự chi phối lại là chuyện khác.
Thấy 10 CPU thì tưởng chạy 10 luồng nhanh gấp 10 lần. Nhưng đo ra chỉ đạt đỉnh 6,4 lần, rồi thêm luồng nữa còn phẳng lì. Hai lý do: '10 CPU' đôi khi là ảo (SMT gộp hai luồng logic một lõi), và ngay cả lõi vật lý thật cũng không đồng đều — có nhân khỏe nhân yếu.
Bấm giờ một lần rồi tin luôn con số? Cùng một đoạn code, 200 lần đo cho con số thấp nhất 23,85 ms nhưng có lần vọt lên 30,50 — cao hơn 28%. Nhiễu chỉ làm phép đo chậm đi chứ không bao giờ nhanh hơn khả năng thật của lõi, nên số nhỏ nhất mới đáng tin, còn trung bình thì bị kéo lệch lên.
Nửa dân lập trình sợ gọi hàm tốn kém nên gộp code lại; nửa kia force-inline mọi thứ. Đo ra một cú gọi hàm chỉ tốn chừng 0,45 nano-giây, và với hàm có việc thật thì con số đó gần như tàng hình. Quan trọng hơn: trình biên dịch đã tự inline hộ bạn đúng chỗ đáng inline rồi.
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.