何時/如何優化通用代碼？

Question

在編寫應用程序代碼時，人們普遍認為過早的微優化是邪惡的，首先進行概要分析是必不可少的，並且關於預先做多少（如果有的話）更高級別的優化存在爭議。 但是，我沒有看到任何關於何時/如何優化通用代碼的指南，這些通用代碼將成為庫或框架的一部分，您將永遠不知道將來如何使用您的代碼。 這有什么指導方針？ 過早的微優化仍然是邪惡的嗎？ 如何將性能與其他設計目標相平衡，例如易用性，易於證明正確性，易於實現和靈活性？

Answer 1

我認為優化必須落后於其他設計目標，例如易用性，易於證明正確性，易於實施和靈活性。

嘗試使用良好實踐智能地編寫代碼並避免明顯的陷阱。 不過，在使用分析器和實際用例之前，不要進行優化。

您仍會遇到一些您從未想過的用例，但如果您從未想過它們，則無法對它們進行優化。

設計良好的框架通常也是一個合理的表現框架。

Answer 2

“如何將性能與其他設計目標相平衡......？”

1. 讓它工作。

2. 優化它直到無法進一步優化。

記下訂單。 避免過早優化意味着在工作后對其進行優化。

優化仍然非常非常重要。 過早優化並不意味着沒有優化。 它意味着在工作后進行優化。

Answer 3

我最近聽到一個關於播客上着名的knuth引用的有趣且非常有啟發性的討論（認為它是深刻的字節），我將嘗試總結：

每個人都知道這句名言： 過早優化是萬惡之源。 。
然而，這只是它的一半。 完整的報價是：

我們應該忘記小的效率，大約97％的時間說：過早的優化是所有邪惡的根源 。

仔細看看這個 - 大約97％的時間說 。
該陳述的另一方約占3％，“小”效率至關重要 。

我的顯示器顯示大約50行代碼。 從統計上來說，每個屏幕上至少有1-2行代碼會包含對性能敏感的內容！ 遵循“現在就做，以后優化它”的共同智慧，當您認為在每個屏幕上都存在可能的性能問題時，這似乎不是一個狡猾的計划。

恕我直言，你應該總是考慮性能。 在通過分析/測試證明之前，您不應該花費大量精力或犧牲可維護性，但是您應該在腦海中完成它。

我個人將此應用於這樣的通用代碼：
你一定會在某個地方有一些代碼，當你寫它時你會認為“這會很慢”，或者“這是一個愚蠢的算法，但它現在並不重要，所以我稍后會修復它。” 當你在共享庫中並且你不能斷言方法A只會被調用5個項目時，你應該進入並清理所有這些東西。

一旦你把這些東西分類出來，我就不會再費勁了。 也許在你的單元測試中運行探查器，以確保沒有任何愚蠢的人通過，但否則等待來自你的庫的消費者的反饋。

Answer 4

我的經驗法則是：

不優化

完整的規則實際上是：

如果您沒有指標，請不要優化

這意味着如果您沒有測量性能並生成具體指標 ，則不應該做任何事情來使代碼執行得更好。

畢竟： 沒有指標，你怎么知道要優化什么？

一旦你進行了一些分析，你可能會對系統性能瓶頸的位置感到驚訝......根據我的經驗，通常情況下相對較小的變化會產生巨大的影響。

Answer 5

你是對的並不總是清楚你的時間最好的降壓在哪里。 您最好的選擇是成為您的框架以及其設計者的用戶。

在非平凡的應用程序中使用您自己的框架，嘗試運用所有功能。 您使用的越多，您就會發現哪些是您最需要的最佳選擇。

此外，盡可能頻繁地獲得其他用戶的反饋和建議。 您將不可避免地發現其他人希望與您永遠不會想到的框架有關。

Answer 6

我認為最好的方法是為您的框架提供一套非常好的用例。 只有這樣，您才能充分了解性能是否足以滿足其預期用途。

當然，你永遠不會知道某人將來會如何使用你的框架（在我職業生涯的早期，它從未讓我驚訝於用戶使用我的軟件的創造性方式 - 我的方式從來沒有想過！）但考慮到你認為它將如何被使用應該會讓你在那里大部分時間。