Delphi XE是否比Delphi 2007生成更快的代碼？

Question

我主要將Delphi 2007用於不需要Unicode的項目。

最近我一直在想德爾福XE，因為

• 每個人都稱贊它；
• 內置SVN支持

我想知道，編譯器中是否有任何增強功能使Delphi XE生成的代碼比Delphi 2007更快，我在說的是：

• 更好地消除無效代碼（delphi 2007很不錯，但不能消除100％的無效代碼）
• 循環展開（ala C的O3優化級別）
• 自動內聯短程序
• 減少多線程代碼中的開銷。

編輯

在此頁面上： http : //www.embarcadero.com/products/delphi/whats-new

它列出： Improved compiler performance那么究竟要改進什么呢？

Answer 1

兩分，我的兩分錢：

1.對於我們的開源ORM框架

使用Delphi 7，Delphi 2007和Delphi 2010編譯器運行單元測試時，我發現Delphi 7和Delphi 2007之間的速度有所提高，但在Delphi 2007和2010之間卻沒有明顯的提高。發現Delphi 2010生成的代碼甚至還有些不足慢點。 我手頭沒有Delphi XE編譯器，但我想它與Delphi 2010有點相同-主要是修復有關泛型AFAIR的錯誤。

編寫低級Pascal代碼並使用事件探查器時，我在asm視圖（Alt-F2）中花費了大量時間。 因此，我通常會注意到Delphi編譯器版本之間的差異。

恕我直言，主要的改進確實是方法和函數/過程的inline關鍵字，在Delphi 2007中可用，而在Delphi 7中則不可用。另一個改進是更積極的寄存器重用。

浮點生成的代碼仍然很慢，有時甚至很糟（即使不再需要，仍然會生成FWAIT，並且內聯浮點代碼甚至比沒有內聯更糟糕 ！

我們的框架有趣的是，所有這些測試都是使用自己的低級單元來處理大量數據的，這些單元以非常微妙的帕斯卡編碼，以獲得最佳性能。 所提供的單元測試（超過5,400,000個單獨測試）適用於真實數據（數字轉換或UTF-8文本處理），具有許多不同的過程，包括低級轉換，文本解析，對象分配，多線程和客戶端/服務器方向。 因此，在這里，編譯器生成的代碼確實有所作為。

該代碼主要在我們的框架內。 我們使用自己的RawUTF8字符串類型，而不是通用字符串。 因此，瓶頸不是VCL也不是Windows API，而僅僅是純Delphi編譯的代碼。 實際上，即使對於UTF-8編碼或數字轉換，我們也避免了大多數API調用。

當然，我使用PUREPASCAL條件集嘗試了該基准測試，即沒有在asm中運行優化的部分，而是僅依靠“純pascal”代碼。

2.對於SynLZ壓縮單元

關於速度的另一個很好的實驗是編寫和分析我們的SynLZ壓縮單元 。 通過LZ壓縮算法的這種優化實現，壓縮速度比zip快20倍，解壓縮快3倍。 實際上，它在壓縮率和解壓縮速度方面與LZO競爭，但在壓縮方面比LZO快得多：SynLZ能夠以與解壓縮相同的速率壓縮數據。 這種對稱的實現在壓縮世界中很少見。

它僅涉及整數算術和位邏輯，哈希表中的填充和查找以及內存復制。

我們編寫了一些非常優化的Pascal代碼，然后使用Delphi 7和Delphi 2009對其進行了編譯。

Delphi 2009生成的代碼明顯比Delphi 7快。 生成的代碼確實更好，寄存器重用也更好。

通過手工調整的匯編程序性能分析，我們獲得了更好的性能。 例如，使用zip壓縮6 KB XML文件的速度為14 MB / s，使用LZO壓縮速度為185 MB / s，使用Delphi 2009 pascal版本的SynLZ壓縮速度為184 MB / s，使用我們最終調整的asm版本壓縮為256 MB / s。 SynLZ。

結論：

對於涉及整數處理，文本解析或內存的代碼生成，我認為Delphi XE比Delphi 7更快，但應該與Delphi 2007處於同一級別。內聯是主要的新功能，可以加快開發速度。很多代碼。

但是對於實際的應用程序，速度的提高不會很明顯。 在某些特定情況下，大約為10％或20％，而不是更多。 算法始終是提高性能的關鍵。 Delphi 7已經是一個不錯的編譯器。

對於浮點算法，如今已不推薦使用Delphi編譯器。 我希望64位編譯器中的SSE代碼可以在此處更改結果。

為了直接回答您的問題，在Delphi 2010或XE中，沒有自動內聯或自動循環展開AFAIK。 而且多線程代碼中的開銷不是編譯器的一部分，而是庫（FastMM4，引用計數等）上的開銷。 因此，我認為Delphi XE不會比Delphi 2007產生更快的代碼。

Answer 2

我對Delphi XE編譯器的非正式測試表明，在涉及使用泛型的許多情況下，代碼生成明顯更正確，並且某些困擾Delphi 2009、2010時代的編譯器內部故障（錯誤）現在已經出現。固定。 在許多情況下，當在IDE中反復重建時，使用鏈接到程序包的泛型的Delphi 2010代碼在IDE中重復生成時，將導致在編譯和鏈接期間DCP文件輸出損壞或神秘的編譯器內部錯誤。

如果是我，我會寫在發行說明中，“我們修復了錯誤”。 （我撤消了“有史以來最好的”一詞，因為似乎人們認為我的意思是作為我當時的雇主的廣告，我以前是為Embarcadero工作的。） 我認為所有這些都被平滑化為“性能”一詞，其中性能被理解為“正確性”，並且“可靠地完成其工作，並且沒有故障”。

至於速度，就其運行時性能和編譯器的性能而言，“以更快的速度構建項目”方面，我還沒有發現與Delphi 2009、2010或XE相比，分析代碼在統計上有顯着差異。

自從詢問了Delphi 2007以來，您應該意識到類型發生了巨大的變化（從String = AnsiString到String = UnicodeString）。 對於相同的代碼，有些事情會變慢，有些事情會更快，而且如果您不了解很多代碼，那么在2010年重新編譯2007代碼會發生什么是100％不可能的。 如果您以前過分依賴WideString，現在可以改用UnicodeString，則由於UnicodeString性能要比WideString性能好得多，因此您的代碼將更快。 一些delphi程序在win32內部（例如當您使用Memo公共控件時）在代碼中安靜地（幾乎是不可見地）花費大量時間將ansi數據轉換為unicode數據。 另一方面，某些以前使用字節大小的字符串的東西現在將使用字大小的字符串，因此某些地方的內存使用量將增加，並且某些操作可能會變慢。 對於正確移植的代碼，最有可能的最終結果是（如果您為2007年編寫了這些代碼，則必須對大多數應用程序進行一些更改才能在XE中構建它們），如果有的話，“原始性能”將出現微小的凈降低。

但是，Delphi XE可以在IDE中一遍又一遍地構建項目，並且更重要的是進行重建和重建，而不會發生意外，並且絕不會對我造成崩潰。 Delphi 2007一直讓我崩潰。 Delphi 2007還具有數百個令人討厭的編譯器錯誤，這些錯誤會使我發瘋。 編譯碼速度甚至不是升級的主要原因，可靠性是。

在我一直使用的大型項目中，Delphi 2007、2009和2010經常會在第二或第三次重建某些復雜軟件包時崩潰。 在2009年和2010年，大量使用泛型的軟件包特別容易使IDE崩潰。 即使當我在繁重的泛型代碼中使用XE時，它也是穩定的，這是發行說明可能在談論的“性能”改進。 我稱其為“錯誤修復”。我們稱鍬為鍬。

（刪除最后一段，因為人們認為這是一個廣告）

Answer 3

我看不到任何證據可以證明代碼生成有任何重大改進。 我不知道自從Delphi 5以來，在代碼生成方面有任何非常重要的改進。實際上，我從來沒有發現我的代碼在升級后運行得更快，並且可以追溯到Delphi 2。

Answer 4

今天，Delphi編譯器已經過時了，正在被重寫。 XE的改進似乎是微不足道的，並且編譯器實際上並不能真正利用最新的處理器功能和指令集（它大多停留在80386時代，但是對於某些使用手寫匯編程序來利用以下代碼的RTL代碼而言）更現代化的功能）。 XE編譯器可能比以前的版本更可靠（因為D7的質量變得非常可變），但是總體性能的提高將需要對編譯器進行全面檢查，以使其進入XXI世紀。 已經進行了此操作，但是尚不知道下一個發行版是否將僅具有較新的64位編譯器，並且仍然具有舊的32位編譯器，或者32位編譯器也具有新的代碼庫。

Answer 5

這是到embaracadero的鏈接

http://www.embarcadero.com/products/delphi/whats-new

向下快速瀏覽頁面中的內容

“語言，編譯器和庫的增強”

他們提到了編譯器的改進。 這里的內容不多，但他們也不會說也是您的回答。 那就是如果他們有什么專業，他們可能會吹牛。