最佳化程式碼速度/如何最佳最佳化？
在最佳化之前，您需要做的第一件事是確保您的程式碼有許多自動化測試，並且測試覆蓋率很高。最佳化程式碼（或任何其他型別的修改）可能會破壞某些功能，而自動化測試可能會（並且希望）捕獲到這些問題。
接下來，您需要確保您的程式碼是模組化的。重複程式碼和其他導致程式碼非模組化的屬性會阻止對程式碼瓶頸進行清晰的效能分析。
在更改程式碼以“最佳化”它之前和之後，重要的是要 使用好的軟體效能分析器對程式碼進行效能分析。有許多 效能分析工具。效能分析將有助於顯示哪些程式碼執行時間不長，因此最好不要在其中投入大量的最佳化工作。應該首先最佳化最耗時的任務。
需要一些專業知識才能瞭解如何正確分析效能分析器給出的結果，以及檢視需要最佳化的內容。例如，一些 I/O 密集型例程可能看起來很耗時，但實際上這種時間無法有效地消除，因為 I/O 量很小（但仍然相對耗時）。我認為進一步討論效能分析的這一方面與本文的任務無關，因此我不會在這裡討論它。
最後，讓某人審查程式碼並對其中發現的速度瓶頸進行一般性評論是一個好主意。引用 Eric Raymond 在 "大教堂與集市" 中的一句話：“只要有足夠多的眼睛，所有 bug 都將變得淺顯易懂”。
一位評論了本文初稿的人說，我沒有足夠重視效能分析，並說“效能分析是唯一有效的最佳化方法”。雖然我同意應該在最佳化之前進行效能分析，但我強烈反對效能分析是唯一最佳化方法的觀點。
例如，有可能在嘗試實現其他目標時意外地進行最佳化。有時，我透過更改程式碼來解決 Windows NT 上的堆疊溢位問題，從而提高了 Freecell Solver 的效能。此外，有時程式設計師可以意識到，以某種方式更改程式的某個方面將提高效能，而無需對程式碼進行效能分析。
最後，有時對程式碼進行效能分析（至少使用現有的有限工具）並不能告訴你很多資訊。在我的一個專案中，在進行效能分析後，最耗時的函式佔用了大約 15% 的時間，而其他最熱門的候選者只佔用了幾個百分點。那麼我應該在這裡對什麼進行效能分析呢？
因此，雖然效能分析很重要，但它並不是唯一有效的最佳化方法，有時需要採用不同的方法。