Tín hiệu khứ hồi 17µs, tôi suýt kết 'chậm gấp 14 lần pipe'. Nhưng đo pipe cùng điều kiện cũng 16µs — biến ẩn là ghim lõi khác nhau, không phải tín hiệu. Kèm bẫy gộp tín hiệu: gửi SIGUSR1 100 lần chỉ nhận 1, còn tín hiệu thời gian thực xếp hàng đủ 100.
Tưởng throughput hàng đợi chỉ phụ thuộc tốc độ xử lý, hoặc hàng đợi càng lớn càng nhanh? Tôi đo: đẩy/lấy từng phần tử chỉ 6,8 triệu op/s vì chi phí đồng bộ mỗi lần bàn giao, gom lô lên 50,6 (7,4 lần), và kích thước hàng đợi chỉ giúp tới điểm bão hòa. Kẻ giết throughput là đồng bộ per-item, không phải xử lý.
Một syscall (getpid) tốn ~120 ns, gấp ~55 lần một lời gọi hàm (~2 ns) — vì phải vượt vào kernel. Tôi tưởng glibc cache pid nên getpid rẻ; strace chứng minh nó trap mỗi lần (5 gọi = 5 syscall). glibc đã bỏ cache đó từ 2017 để đổi lấy tính đúng. Đừng tin sự thật nhớ được về hệ thống — đo trên máy thật.
Chạm 64MB bộ nhớ mới tôi tưởng gây 16.384 lỗi trang; getrusage ra 32 — vì trang lớn trong suốt (THP) 2MB, một lỗi lo trọn 2MB. Tắt THP ra đúng 16.384 (lệch 512 lần). Và đọc file đã nằm trong cache gần như không gây lỗi trang nặng nào. Kích thước trang và page cache là biến ẩn — phải đo, đừng nhẩm.
Code không nhánh (branchless) luôn nhanh hơn if? Đo trên host ARM: khi nhánh khó đoán (dữ liệu ngẫu nhiên), branchless nhanh gấp 3 lần vì né được dự đoán sai. Nhưng khi nhánh dễ đoán và thân điều kiện rất đắt (8 phép chia, hiếm khi chạy), bản có if lại thắng vì bỏ qua được việc đắt. Và nhiều khi trình biên dịch đã tự bỏ nhánh giúp bạn rồi mà không hay.
A giữ SELECT FOR UPDATE trên một hàng: B ghi cùng hàng chờ 2 giây, nhưng ghi hàng khác hay đọc thuần không chờ mảy may. Tôi tưởng khóa chặn tất cả — hóa ra nó chỉ chặn người ghi cùng hàng, đọc luôn qua nhờ MVCC. Và khóa hai hàng ngược thứ tự thì deadlock, PostgreSQL tự hủy một bên.