Điều đáng chú ý là trích dẫn ban đầu của Knuth đến từ một bài báo mà anh ấy viết về việc quảng bá việc sử dụng gotoở các khu vực được đo lường và lựa chọn cẩn thận như một cách để loại bỏ các điểm nóng. Trích dẫn của anh ấy là một lời cảnh báo mà anh ấy thêm vào để biện minh cho lý do anh ấy sử dụng gotođể tăng tốc các vòng lặp quan trọng đó.
[...] một lần nữa, đây là một tiết kiệm đáng chú ý trong tốc độ chạy tổng thể, giả sử, giá trị trung bình của n là khoảng 20 và nếu quy trình tìm kiếm được thực hiện khoảng một triệu lần trong chương trình. Các cách tối ưu hóa vòng lặp như vậy [sử dụng gotos] không khó học và như tôi đã nói, chúng chỉ thích hợp trong một phần nhỏ của chương trình, nhưng chúng thường mang lại tiết kiệm đáng kể. [...]
Và tiếp tục:
Sự khôn ngoan thông thường được chia sẻ bởi nhiều kỹ sư phần mềm ngày nay kêu gọi bỏ qua hiệu quả trong phạm vi nhỏ; nhưng tôi tin rằng đây chỉ đơn giản là một phản ứng thái quá đối với những hành vi lạm dụng mà họ thấy đang được thực hiện bởi các lập trình viên ngu ngốc, những người không thể gỡ lỗi hoặc duy trì các chương trình "được tối ưu hóa" của họ. Trong các lĩnh vực kỹ thuật đã được thiết lập, một cải tiến 12%, dễ dàng đạt được, không bao giờ được coi là biên; và tôi tin rằng quan điểm tương tự sẽ phổ biến trong kỹ thuật phần mềm. Tất nhiên tôi sẽ không bận tâm đến việc tối ưu hóa như vậy cho một công việc oneshot, nhưng khi đặt câu hỏi về việc chuẩn bị các chương trình chất lượng, tôi không muốn giới hạn bản thân mình trong các công cụ phủ nhận tính hiệu quả của tôi [tức là các goto
tuyên bố trong bối cảnh này].
Hãy ghi nhớ cách anh ấy sử dụng "tối ưu hóa" trong dấu ngoặc kép (phần mềm có thể không thực sự hiệu quả). Cũng lưu ý rằng anh ấy không chỉ chỉ trích những lập trình viên "ngu xuẩn và ngu ngốc" này mà còn cả những người phản ứng bằng cách gợi ý bạn nên luôn bỏ qua những điểm kém hiệu quả nhỏ. Cuối cùng, đến phần thường được trích dẫn:
Không có nghi ngờ rằng chén hiệu quả dẫn đến lạm dụng. Các lập trình viên lãng phí một lượng lớn thời gian để suy nghĩ hoặc lo lắng về tốc độ của các phần không quan trọng trong chương trình của họ, và những nỗ lực về hiệu quả này thực sự có tác động tiêu cực mạnh khi xem xét việc gỡ lỗi và bảo trì. Chúng ta nên quên đi những hiệu quả nhỏ, ví dụ như 97% thời gian; tối ưu hóa quá sớm là gốc rễ của mọi điều ác.
... và sau đó là một số thông tin khác về tầm quan trọng của các công cụ lập hồ sơ:
Thường là sai lầm khi đưa ra các phán đoán trước về những phần nào của chương trình thực sự quan trọng, vì kinh nghiệm phổ biến của các lập trình viên đã sử dụng các công cụ đo lường là các dự đoán trực quan của họ không thành công. Sau khi làm việc với các công cụ như vậy trong bảy năm, tôi tin rằng tất cả các trình biên dịch được viết từ bây giờ trở đi nên được thiết kế để cung cấp cho tất cả các lập trình viên phản hồi cho biết phần nào trong chương trình của họ đang tốn kém nhất; thực sự, phản hồi này sẽ được cung cấp tự động trừ khi nó đã được tắt cụ thể.
Mọi người đã sử dụng sai trích dẫn của anh ấy ở khắp nơi, thường cho rằng các tối ưu hóa vi mô là quá sớm khi toàn bộ bài báo của anh ấy ủng hộ các tối ưu hóa vi mô! Một trong những nhóm người mà anh ấy đang chỉ trích, những người lặp lại "sự khôn ngoan thông thường" này vì anh ấy luôn bỏ qua những hiệu quả nhỏ thường lạm dụng trích dẫn của anh ấy vốn được hướng dẫn ban đầu, một phần, chống lại những người không khuyến khích tất cả các hình thức tối ưu hóa vi mô .
Tuy nhiên, đó là một trích dẫn ủng hộ các tối ưu hóa vi mô được áp dụng thích hợp khi được sử dụng bởi một tay có kinh nghiệm đang nắm giữ một trình biên dịch. Tương tự tương tự ngày nay có thể là, "Mọi người không nên quá mù quáng vào việc tối ưu hóa phần mềm của họ, nhưng trình phân bổ bộ nhớ tùy chỉnh có thể tạo ra sự khác biệt lớn khi được áp dụng trong các lĩnh vực chính để cải thiện vị trí tham chiếu" hoặc, " Mã SIMD viết tay sử dụng SoA thực sự rất khó để duy trì và bạn không nên sử dụng nó khắp nơi, nhưng nó có thể tiêu tốn bộ nhớ nhanh hơn nhiều khi được áp dụng một cách thích hợp bởi một tay có kinh nghiệm và hướng dẫn. "
Bất cứ khi nào bạn đang cố gắng quảng bá các tính năng tối ưu hóa vi mô được áp dụng cẩn thận như Knuth đã quảng cáo ở trên, bạn nên đưa ra tuyên bố từ chối trách nhiệm để ngăn cản những người mới sử dụng quá hào hứng và mù quáng tham gia vào việc tối ưu hóa, chẳng hạn như viết lại toàn bộ phần mềm của họ để sử dụng goto. Đó là một phần những gì anh ấy đang làm. Câu nói của anh ấy thực sự là một phần của một tuyên bố từ chối trách nhiệm lớn, giống như việc ai đó thực hiện một chiếc mô tô nhảy qua một hố lửa rực lửa có thể thêm một lời tuyên bố từ chối trách nhiệm rằng những người nghiệp dư không nên thử điều này ở nhà đồng thời chỉ trích những người cố gắng mà không có kiến thức và thiết bị phù hợp và bị thương .
Những gì ông cho là "tối ưu hóa quá sớm" là những tối ưu hóa được áp dụng bởi những người không biết họ đang làm gì một cách hiệu quả: không biết liệu tối ưu hóa có thực sự cần thiết hay không, không đo lường bằng các công cụ thích hợp, có thể không hiểu bản chất của trình biên dịch hoặc kiến trúc máy tính của họ, và hơn hết là "ngu xuẩn xuẩn xuẩn", nghĩa là họ đã bỏ qua những cơ hội lớn để tối ưu hóa (tiết kiệm hàng triệu đô la) bằng cách cố gắng kiếm từng xu, và tất cả trong khi tạo mã, họ không thể gỡ lỗi và duy trì hiệu quả hơn.
Nếu bạn không phù hợp với danh mục "xuẩn ngốc và xuẩn ngốc", thì bạn không sớm tối ưu hóa theo tiêu chuẩn của Knuth, ngay cả khi bạn đang sử dụng gotođể tăng tốc một vòng lặp quan trọng (điều khó xảy ra để giúp nhiều chống lại các trình tối ưu hóa ngày nay, nhưng nếu có và trong một lĩnh vực thực sự quan trọng, thì bạn sẽ không tối ưu hóa sớm). Nếu bạn thực sự áp dụng bất cứ điều gì bạn đang làm trong những lĩnh vực thực sự cần thiết và họ thực sự được hưởng lợi từ nó, thì bạn đang làm rất tốt trong mắt Knuth.