最佳化程式碼速度/結論
當我向 IRC 上的一些人提到這篇文章時（當時它還沒有完成），有人說“最佳化的第一條規則是‘不要！’”。我認為這種態度有害。雖然我同意“過早最佳化是萬惡之源”，但有時程式碼執行速度太慢，需要最佳化。如果你的程式碼是Joel Spolsky 所謂的“縮略包裝”（即：出售或以其他方式分發並提供給公眾消費的程式碼），那麼你通常不能假設它需要多快，越快越好。
速度和最佳化其他資源是程式總體抽象質量的重要因素之一。如果你的程式很慢，很可能會讓你的使用者感到沮喪和不高興，這將是你作為軟體開發者的使命的失敗。因此，重要的是你的程式足夠快，即使不是很快。
本文旨在解釋最佳化的“為什麼”、“什麼”和“如何”的程度較低。我希望我能成功，並且閱讀過它的人將更願意最佳化他們的軟體，並且對如何做到這一點更加了解。
Jon Bentley 在《程式設計珠璣第 2 版》ISBN 0-201-65788-0 中廣泛討論了各種最佳化。這是一本非常值得推薦的讀物。他還在書中推薦了他的絕版書《編寫高效程式》ISBN 0-13-970244-X，以進一步討論該主題。在《演算法設計手冊，第二版》ISBN 978-1848000698 中也有很多關於最佳化的討論。
Dave Jones 的論文“為什麼使用者空間很爛”詳細介紹了 GNU/Linux 使用者空間應用程式中一些損害效能的不良做法。Steve Souders 做了一個有趣的名為“速度的幻覺”的演講。一篇名為“過早最佳化是萬惡之源”是萬惡之源 的部落格文章也提供了一些見解。
最後要注意，在 2018 年，我寫了一篇關於“軟體質量如何改進或惡化”的論文摘要。
我要感謝 Daan 對這篇文章表現出極大的興趣，並感謝他不斷地鼓勵和提供意見。Limbic_Region 透過電子郵件為這篇文章提供了一些有用的意見。一些人對這篇文章做出了貢獻：Jguk、Dallas1278 以及 IP 地址 84.27.42.81、85.146.243.13、203.196.46.108、70.176.53.73 和 213.129.10.120。我還想感謝所有在我的文章中引用或參考過的來源的創作者。
