Tưởng VSZ là bộ nhớ tiến trình dùng, và cộng RSS các tiến trình ra tổng RAM? Tôi đo thử: malloc 3GB chưa chạm cho VSZ ~3GB nhưng RSS chỉ ~1MB; và RSS 1016KB nhưng PSS chỉ 453KB vì trang thư viện chia sẻ bị đếm đủ trong RSS. Ba con số, ba nghĩa — chọn nhầm là hiểu sai hoàn toàn.
Tưởng throughput cao là hệ nhanh, và đo latency bằng trung bình là đủ? Tôi đo từng thao tác dưới tranh chấp: throughput và latency là hai thứ khác nhau có thể cùng tệ đi, và latency là một phân phối lệch — ở 8 luồng trung vị chỉ 125ns nhưng p99 vọt lên 32.292ns, gấp 258 lần. Trung bình giấu cái đuôi mà người dùng thật sự gặp.
Trie luôn tốt hơn hash cho chuỗi? Tôi đo thử: trie tốn RAM gấp 11 lần hash (256 MB vs 23 MB) và exact match chỉ ngang nhau. Nhưng trie thắng tuyệt đối một việc hash không làm nổi: tra tiền tố / autocomplete — 94 lần nhanh hơn, vì hash phải quét toàn bộ tập. Chọn theo có cần prefix hay không.
Bật -O3, vòng nhân mảng float nhanh 3,9 lần nhờ NEON làm 4 float mỗi lệnh. Nhưng chỉ thêm một phụ thuộc chuỗi là trình biên dịch lặng lẽ bỏ vector hóa, tụt về scalar chậm 11,6 lần — không một dòng cảnh báo. SIMD không phải phép màu của cờ, mà là phần thưởng cho vòng viết đúng dạng. Tôi đo.
Tin lời khuyên kinh điển 'subquery chậm, viết lại thành JOIN'. Đo ngược: IN và EXISTS ra kế hoạch y hệt (semi join), và semi join đó nhanh gấp 10 lần JOIN+DISTINCT của tôi — vì DISTINCT nối cả triệu cặp rồi mới khử trùng. Nhãn 'subquery hay join' gần như không quyết định tốc độ; cái quyết định là việc truy vấn thật sự cần làm, đọc được trong EXPLAIN.
Khi số giá trị sống cùng lúc vượt số thanh ghi, trình dịch phải đổ bớt ra stack (spill). Nhưng áp lực đến từ giá trị sống đồng thời, không phải số biến khai báo — 40 biến dùng tuần tự vẫn 0 tràn. Và chi phí tràn thật, khi cô lập đúng, chỉ ~3%. Đo thật trong container.