Họ đang đo gì
Bạn có phân biệt được tối ưu hoá có căn cứ với tối ưu hoá theo phản xạ không.
Trả lời ngắn~30 giây
Không. 50² là 2.500 phép — vài micro giây, và code đơn giản hơn thì ít bug hơn. Nhưng mình sẽ hỏi thêm hai câu: n có phải luôn dưới 50 không, hay đó chỉ là quan sát hiện tại; và ai bảo đảm điều đó — có ràng buộc ở tầng dữ liệu, hay chỉ là “tới giờ vẫn thế”. Nếu n do người dùng kiểm soát thì đây không còn là câu hỏi hiệu năng nữa mà là câu hỏi bảo mật.
Giải thích sâu
Điều đáng nói là hầu hết vấn đề hiệu năng thật không nằm ở độ phức tạp thuật toán mà ở I/O: một truy vấn database, một lời gọi mạng, một lần đọc đĩa. Một vòng lặp O(n²) trên 50 phần tử trong bộ nhớ nhanh hơn hàng nghìn lần so với một lời gọi HTTP duy nhất. Dành thời gian tối ưu vòng lặp trong khi hàm đó gọi API ba lần là ưu tiên sai một cách rất phổ biến.
Cái làm câu trả lời này khác với “đừng bao giờ tối ưu sớm” là ở chỗ có điều kiện rõ ràng. Mình sẽ tối ưu nếu: n do đầu vào bên ngoài quyết định, hoặc đoạn code nằm trong đường nóng đã ĐO được là chậm, hoặc phiên bản nhanh hơn không phức tạp hơn đáng kể. Điều kiện thứ ba hay bị quên — đôi khi cách viết O(n) cũng ngắn gọn y hệt, và lúc đó không có lý do gì để chọn cách chậm.
Câu hỏi tiếp theo họ sẽ hỏi
?Làm sao chặn n lớn lên?
Đặt giới hạn tường minh và có test cho nó, chứ đừng chỉ ghi bình luận. Một if (items.length > 100) throw cộng một test là hợp đồng thật; một dòng // n luôn nhỏ là hy vọng.
Trả lời thế này là mất điểm
- Tối ưu mọi thứ theo phản xạ. Code phức tạp hơn cần đọc nhiều lần trong nhiều năm, còn vài micro giây thì không ai đo được.
- Trả lời “không” mà không hỏi n từ đâu ra. Nếu n do người dùng gửi lên thì câu trả lời đảo ngược hoàn toàn.
Nguồn
- Donald Knuth — Structured Programming with go to Statements (nguồn của câu “premature optimization”, kèm phần bị cắt mất)