O(log n) đánh bại O(n) — nên ai cũng mặc định dùng nhị phân. Nhưng đo ra ở n=64 tìm tuyến tính nhanh hơn (14,5 so 20,2 ns): nhị phân ít bước nhưng mỗi bước là một nhánh 50/50 mà CPU hay đoán sai, còn tuyến tính quét tuần tự CPU đoán trúng suốt. Big-O đếm số bước, bỏ qua giá mỗi bước. Tôi đo bằng C.
Container thấy 10 lõi nhưng cgroup chỉ cho dùng 2: 8 luồng bận chỉ đạt 4 giây-lõi thay vì 16, bị đóng băng 20/21 chu kỳ. nproc vẫn nói dối là 10. App 'chậm' dù host rảnh là bị throttle — chẩn đoán bằng cpu.stat chứ không bằng nproc/top, và đặt thread pool theo quota cgroup.
/proc không phải file trên đĩa — nhân sinh nội dung tại chỗ mỗi lần đọc (nên stat báo 0 byte). Tôi đọc /proc/self/stat để xem CPU mình tăng, mãi được 0/0: self là kẻ đang đọc, không phải chương trình tôi nghĩ. Bốn trạng thái R/S/D/Z và cách chẩn đoán không cần cài gì.
Mỗi .c dịch một mình, không thấy các file khác; linker khớp theo tên chứ không theo kiểu. Một lệch kiểu xuyên file lọt lưới cả trình dịch lẫn linker — chỉ -flto bắt được. Đo thật trong container.
Ai cũng biết compiler tính sẵn 2+3 thành 5. Tôi đo xem nó đi xa tới đâu: cùng một hàm ba phép nhân, khi đầu vào là hằng 100 thì gcc gấp toàn bộ thành một literal 64-bit (5 lệnh, 0 phép nhân, 0 ns); khi đầu vào từ volatile thì phải tính đủ (22 lệnh, 3 phép nhân, 0,99 ns). Ranh giới nằm ở một câu hỏi.
Trên cột lệch 99% 'done', index đầy đủ 30 MB đánh cả những hàng chẳng ai tra; partial index chỉ 'active' còn 240 kB — nhỏ hơn 128 lần, ghi rẻ hơn 2 lần. Nhưng tạo xong rồi WHERE status=$1 vẫn seq scan cả bảng, vì planner không chứng minh được tham số khớp điều kiện index. Cách để index thật sự được dùng.