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.
Nested loop join với bảng ngoài nhỏ + bảng trong có index chỉ 0,027ms; cùng 2000 hàng nhưng bỏ index thì 156ms — chậm 83 lần. Và tôi suýt tưởng join miễn phí vì đọc actual time 0,001ms mà quên nhân với loops=1999. Đọc EXPLAIN phải nhân thời gian node trong với số vòng lặp.
next()+next() cho 21 trên gcc/aarch64, nhất quán mọi lần — nhưng thứ tự đó không được chuẩn bảo đảm, và i=i++ + ++i là UB. Nhất quán trên một máy không phải 'được định nghĩa'. Đo thật trong container.
Lock-free không dùng khóa nên luôn nhanh hơn mutex? Đo ra: với ít luồng thì atomic nhanh hơn hẳn (1 luồng mutex 4,1 ns vs atomic 1,6 ns), nhưng 8 luồng tranh gay gắt một biến thì atomic fetch_add chỉ ngang mutex (20,8 vs 22,1 ns) và CAS-loop tự viết tệ hơn mutex 6,8 lần (141,5 ns) vì thử lại liên tục. Và mutex không tranh chỉ tốn vài ns.
Giữ nhiều phiên bản của một cấu trúc thì phải copy cả nó mỗi lần sửa, tốn O(n)? Đo ra: một persistent vector kiểu trie nhánh 32 chỉ copy đường dẫn tới phần đổi — update nhanh hơn copy cả mảng 319 lần, và mỗi phiên bản mới tốn 1,76 KB thay vì 4 MB, ít hơn 2345 lần. Còn đọc thì chỉ chậm hơn mảng phẳng 1,1 lần vì nhánh rộng giữ cây nông.
sizeof một struct không phải tổng kích thước các trường: struct trộn kiểu cộng lại 15 byte mà sizeof=32 vì đệm căn lề. Sắp lại đúng năm trường đó theo lớn->nhỏ còn 16. Đo sizeof và offsetof thật trong container.
Cứ đo thời gian là biết ngay độ phức tạp? Đo ra: ở n nhỏ hằng số và overhead lấn át nên tỉ số T(2n)/T(n) lung tung (1,0/4,0/1,75), và cache tạo gãy khúc — truy cập ngẫu nhiên nhảy từ 0,9ns (L1) lên 96ns (RAM), khiến vòng O(n) trông siêu tuyến tính. Nhưng đo đúng cách thì tỉ số hội tụ chính xác: O(n)→2,00, O(n log n)→2,07.