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 hàm nóng nhất trong profiler là chỗ cần tối ưu, và CPU bận nghĩa là thiếu CPU? Tôi đo: một chương trình 8 luồng chỉ đạt song song hiệu quả 1,27 lõi vì chờ khóa 81% thời gian — mà hàm 'nóng' nhất lại hoàn toàn vô can. Đọc profiler đa luồng phải nhìn CPU/wall và thời gian chờ.
Chia là chia, tốn như nhau? Tôi đo và thấy cùng dấu / cho hai chi phí khác hẳn: chia cho hằng số biến thành nhân magic + dịch (vector hóa được, gần như miễn phí), còn chia cho biến là udiv đắt 2,7 lần. Nhưng trong chuỗi phụ thuộc, cái mẹo magic lại không thắng — lợi ở thông lượng, không ở độ trễ.
malloc/free có phải cách cấp phát duy nhất, chi phí không tránh được? Tôi đo thử: một arena allocator cấp phát bằng cách chỉ tăng một con trỏ — nhanh gấp 10 lần malloc — và giải phóng cả lô 10 triệu đối tượng chỉ bằng một phép reset O(1) thay vì free 44 ms. Đổi lại nó không free lẻ được, chỉ hợp khi các đối tượng chết cùng lúc.
shared_ptr tiện nên cứ dùng khắp nơi? Tôi đo thử: mỗi lần copy shared_ptr là một phép đếm tham chiếu atomic, chậm gấp 2,3 lần gán con trỏ thô — và tệ hơn nữa khi nhiều luồng tranh cùng bộ đếm. Trong khi unique_ptr thì gần như miễn phí, nhanh bằng con trỏ thô. Chọn theo có cần chia sẻ sở hữu hay không.
std::string luôn cấp phát heap nên chậm? Tôi đo thử: nhờ SSO, chuỗi ngắn (≤15 ký tự) lưu inline ngay trong đối tượng 32 byte, không malloc — tạo nhanh gấp 3 lần và copy nhanh gấp 5,3 lần chuỗi dài phải malloc. Phần lớn chuỗi thực tế đều ngắn nên chẳng bao giờ chạm heap.
Bên đóng kết nối trước phải nằm TIME_WAIT đúng 60 giây trên Linux, và tcp_fin_timeout (thứ ai cũng khuyên vặn) KHÔNG chỉnh được nó — vì nó điều khiển một trạng thái khác. Đo thật ai gánh TIME_WAIT, bao lâu, và vì sao nó đặt trần ~470 kết nối/giây tới mỗi đích.