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 kiểm null rồi khóa rồi kiểm lại là đủ, và DCL chỉ là mẹo tránh khóa? Tôi đo: fast-path đọc atomic không khóa nhanh 314 lần always-lock — nhưng DCL đúng bắt buộc có rào bộ nhớ (acquire/release), thiếu nó luồng khác thấy con trỏ đã publish mà object chưa khởi tạo xong. Một bug ẩn kỹ tới mức Java mất nhiều năm mới thừa nhận.
Tưởng duyệt mảng và danh sách liên kết tốn như nhau vì cùng O(n)? Tôi đo thử: duyệt 20 triệu phần tử, mảng 0,24ns/phần tử còn linked list 104ns — chậm 442 lần, vì mỗi con trỏ next là một cache miss còn mảng thì được prefetch. Big-O đếm số thao tác, không đếm giá mỗi thao tác.
Ai cũng nói hash table là O(1). Tôi đo thử: O(1) chỉ đúng khi hệ số tải thấp — tải 0,25 tốn 1,17 probe (3,2ns), nhưng đẩy tải lên 0,99 thì probe trung bình nổ lên 43 và tra cứu chậm 10 lần. O(1) là trung bình có điều kiện, không phải bảo đảm vô điều kiện.
Tưởng giới hạn CPU của cgroup giống nice, chỉ cắn khi máy bận? Tôi đo: --cpus=0.5 vẫn chậm 2,2 lần và --cpus=0.25 chậm 6,5 lần dù 9/10 lõi ngồi không. Nó là hạn ngạch tuyệt đối, không phải ưu tiên — và ở hạn ngạch nhỏ còn tệ hơn tỉ lệ.
Tưởng mỗi push_back copy cả mảng nên vector chậm, hoặc grow-by-1 tiết kiệm RAM nên tốt? Tôi đo thử: nhân đôi amortize xuống 2,57ns/push (O(1)) xây 20 triệu phần tử, còn grow-by-1 là O(N²) — chỉ 50 nghìn phần tử đã 1,25 tỷ copy, 3213ns/push, nếu 20 triệu thì mất 7 giờ.
Tưởng mỗi putc/fprintf là một syscall, và stdout luôn được đệm như nhau? Tôi đo thử: stdio đệm trong user-space nên có đệm nhanh hơn không đệm 116 lần (10 triệu write() vs 2442); và mặc định đệm khác nhau tùy stdout là file, pipe hay terminal — thứ quyết định cả tốc độ lẫn output có mất khi crash.