Là một lập trình viên yêu công nghệ, thích viết blog để chia sẻ kiến thức, kinh nghiệm lập trình và những điều thú vị trong thế giới tech.
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.
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.
O_DIRECT bỏ qua page cache, nghe như tối ưu. Nhưng đọc lại từ cache buffered ấm nhanh gấp ~5 lần. O_DIRECT là I/O KHÔNG cache, không phải I/O nhanh. Và lần đo đầu trên bind-mount cho kết quả vô lý vì các tầng cache lồng nhau nuốt luôn cờ direct. Đo thật.
Pipe báo dung lượng 64 KB. Nhưng ghi khối 4097 byte (lố đúng 1 byte qua ranh giới trang) chỉ nhét được 44 KB trước khi write chặn — mất một phần ba. 'Dung lượng pipe' không phải một số duy nhất; chính cỡ khối ghi định hình nó. Và khi đầy, write chặn đúng tới khi bên đọc rút. Đo thật.
Macro trông như hàm nhưng chỉ là dán văn bản: SQ(i++) khiến i tăng hai lần, SQ_BAD(1+2) ra 5 chứ không phải 9. Và một #include kéo theo 37 file. Đo thật bằng gcc -E trong container.
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.