我想選擇編譯器優化來生成最快的應用程序。爲儘可能快的代碼編譯器優化
下列哪個設置應該設置爲true？
還有「生成最快可能的代碼」選項，我明顯地設置爲true。但是，當我將其設置爲true時，以上所有選項仍然設置爲false。
所以我想知道如果任何上述選項將加快應用程序，如果我將它們設置爲true？
所以我想知道如果任何上述選項將加快應用程序，如果我將它們設置爲true？
我知道有些人會討厭我這個，但是這裏沒人能夠如實回答你。您必須嘗試使用和不使用它們的程序，然後分別使用配置文件來查看結果。猜測工作不會在任何地方得到任何人。
編譯器已經做了很多優化的噸（！），無論是否經過您的許可。你最好的選擇是把你的代碼編寫成一個乾淨有組織的問題，並擔心可維護性和可擴展性。正如我想說的：現在編碼，稍後優化。
你可以用不同的編譯選項查看生成的代碼，看看哪個是最快的，但我明白現在很多人沒有這樣做的經驗。
因此，分析應用程序將會很有用。如果有明顯的部分需要速度，請添加一些代碼以執行千次或千萬次，並使用utime()（如果有）。循環應該運行足夠長的時間，以便間歇運行的其他進程不會影響結果 - 十到二十秒是流行的基準範圍。或者運行多個計時試驗。編譯不同的測試用例並運行它以查看最佳效果。
花費一兩個小時玩優化選項很快就會發現大多數效果都很小。然而，同樣的時間花在思考算法的本質並做出小的更改（代碼清除特別有效），通常可以大大提高執行時間。
不要微觀管理個人優化。編譯器編寫者是非常聰明的人 - 只要把它們全部打開，除非你看到一個特定的需要。通過優化代碼（改進函數的算法複雜度等），而不是擺弄編譯器選項，您的時間會更好。
我的其他建議，使用不同的編譯器。英特爾作爲優化編譯器享有盛譽。 VC和GCC當然也是很好的選擇。
非常感謝特里，不幸的是我的雙手綁定在rad-studio-2009編譯器上。 – Seth 2010-01-14 22:41:29
同意編碼和清理有組織的方式 - 但是它不會傷害到找到任何快速優化，你可以做一個IDE選項 – Seth 2010-01-14 05:43:13
切換再次，你不知道它不會傷害，你認爲這也許是對的。正如我所說的，無論如何，任何簡單的優化都在進行，並且在優化構建中（就像你已經啓用的那樣），它會做每個你可以想到的教科書優化，可能更多。 – GManNickG 2010-01-14 06:27:29