D編譯器剖析

Question

如何確定我的d代碼的哪一部分需要很長時間才能編譯？

我試圖使用valgrind，但方法名稱不是很有見地。時間的87％用於在<cycle 7>中，40％的時間在_D4ddmd5lexer5Lexer4scanMFPS4ddmd6tokens5TokenZv

我正在尋找像這樣的：40％的時間花在xy.d，出來的時候，80％拿了各種編譯實例化模板xyz和一個原因是因爲它使用memcpy 99％的時間。

我很感興趣的分析DMD和LDC。

Answer 1

由於D編譯器的前端是用D語言編寫的，與C++類似，使用傳統工具進行分析將比較困難。我在Linux上使用gdb和valgrind等工具並在Windows上使用VisualD等工具取得了一些成功，Mac用戶也是SOL。

您還有其他五個選項：

1. 停止試圖找到在編譯器的具體功能和轉向有關該問題的常識（見下文）
2. 使用的工具，像https://github.com/CyberShadow/DBuildStat。它並沒有給出你所問的確切答案，但如果你想讓一個大型項目編譯得更快，那總比沒有好。
3. 使用-v標誌嘗試查看程序的哪些部分需要一段時間。當然，這是一種非常暴力的方法，可能會讓你一陣子。
4. 修改DMD前端的makefile以使用-profile開關。每次運行DMD時，都會得到一個包含大量信息的配置文件。當然，我認爲這並沒有被嘗試過。你的milage可能會有所不同。
5. 嘗試在其Github問題頁面上詢問LDC團隊。 IIRC他們提供了一個補丁版本來分析他們用於Weka.io代碼庫的情況。

當我說轉向常識時，我的意思是說你的編譯速度慢可能是由於幾個常見問題。例如，當一個SQL查詢花費的時間太長時，我的第一反應就是不試圖分析MySQL服務器代碼。下面是幾個最常見的問題

1. CTFE，而它的速度運行時，是慢。特別是如果你使用遞歸模板如allSatisfy或使用ctRegex等函數。如果你正在做大量的CTFE，並希望以可能較慢的代碼爲代價進行更快的編譯，請考慮將它們切換爲運行時間調用。
2. DMD不會忽略程序中未使用的符號，這意味着如果您導入模塊，代碼生成將發生在模塊中的所有功能上。即使對於選擇性進口也是如此。如果你不使用它們，鏈接器會從結果可執行文件中刪除函數，但是編譯器仍然需要時間來編譯它們。避免像import std.algorithm;或import std.range;這樣的進口。而是使用軟件包特定的導入，如import std.algorithm.iteration : map;。