Cây và list phải dùng con trỏ, đó là cách chuẩn? Tôi đo thử: thay con trỏ 8 byte bằng chỉ số 4 byte vào một arena làm node nhỏ hơn 33%, RAM ít hơn 33%, và tra cứu nhanh 1,86 lần — vì node nằm liền mạch thay vì malloc rải rác. Con trỏ không phải lựa chọn duy nhất, và thường không phải lựa chọn tốt nhất.
Bốn chặng gọi tuần tự tốn 261ms; song song hoá còn 63ms. Nhưng một chặng chậm +100ms đẩy tổng song song lên 172ms — bằng chặng chậm nhất, không phải tổng. Và lần đầu đo, mỗi chặng cõng thêm 40ms lạ mà thủ phạm là chính cái máy chủ tôi tự dựng kẹt Nagle. Bài cuối của sê-ri. Đo thật.
Xin bytes=30000- để tải tiếp chỉ lấy 70 KB còn lại thay vì cả 100 KB; xin một khúc giữa chỉ lấy 100 byte. Nhưng khoảng byte của HTTP bao gồm cả hai đầu còn lát cắt Python thì không — trộn lẫn là mỗi tệp thiếu đúng một byte và hỏng âm thầm. Đo thật, kèm cái bẫy off-by-one kinh điển.
Viết một vòng lặp, bọc đồng hồ hai đầu, chia cho số phần tử — nghe là xong. Nhưng cùng một đoạn code, tôi đo được 0 nano-giây (nhanh vô hạn), rồi 0,57, rồi 2,62 ns, tùy vào những cái bẫy mà trình biên dịch giăng sau lưng. Chỉ một cách đo là ra con số thật.
Một khung WebSocket gửi 'hi' chỉ tốn 8 byte trên dây. Nhưng giữ 3000 kết nối mở ngốn 45,8 KB mỗi cái trên máy chủ Python — trong khi 3000 socket TCP trần chỉ 0,1 KB. Tôi định đổ tội cho bộ đệm nhân, rồi một phép đo đối chứng lật ngược: cái đắt là runtime, không phải kết nối. Đo thật.
Tưởng fork đắt vì phải sao chép cả bộ nhớ? Tôi đo: Copy-on-Write nên fork KHÔNG chép dữ liệu — chỉ 74µs, 1,6 lần một luồng. Nhưng CoW không làm fork miễn phí theo kích thước: fork sau khi cấp 256MB chậm 1,86 lần vì vẫn phải nhân đôi bảng trang. CoW cắt chép dữ liệu, không cắt chép bảng trang.