D 编译器分析
D compiler profiling
如何找出我的d代码的哪一部分编译时间很长？
我尝试使用 valgrind，但方法名称不是很有见地。 87% 的时间花在 <cycle 7>，40% 的时间花在 _D4ddmd5lexer5Lexer4scanMFPS4ddmd6tokens5TokenZv
我正在寻找这样的东西：40% 的时间花在 xy.d 上，其中 80% 的时间花在编译模板 xyz 的各种实例化上，这是一个原因是因为它使用了 memcpy 99% 的时间。
我有兴趣分析 DMD 和 LDC。
由于 D 编译器前端是用 D 编写的，与 C++ 等工具相比，使用传统工具进行分析会相当困难。我在 Linux 上使用 gdb 和 valgrind 等工具以及在 Windows 上使用 VisualD 等工具取得了一些成功，Mac 用户有点 SOL。
您还有五个其他选择：
- 停止尝试在编译器中查找特定函数并转向有关问题的常识（见下文）
- 使用 https://github.com/CyberShadow/DBuildStat 这样的工具。它不会给你你所询问的确切答案，但如果你想让一个大型项目编译得更快，那总比没有好。
- 使用
-v 标志尝试查看程序的哪些部分需要一段时间。当然，这是一种非常蛮力的方法，可能会花费您一段时间。
- 修改 DMD 前端的 makefile 以使用
-profile 开关。每次你 运行 DMD 你都会得到一个包含很多信息的配置文件。当然，我认为这从未被尝试过。您的里程可能会有所不同。
- 尝试在他们的 Github 问题页面上询问 LDC 团队。 IIRC 他们制作了一个用于分析的补丁版本，用于 Weka.io 代码库。
当我说 turn to common knowledge 时，我的意思是说你的编译速度慢很可能是由于一些常见问题。例如，当 SQL 查询花费的时间太长时，我的第一反应是不会尝试分析 MySQL 服务器代码。以下是几个最常见的问题
- CTFE 虽然可以加快您的 运行 时间，但 很慢 。特别是如果你正在做像
allSatisfy 这样的递归模板或者你使用像 ctRegex 这样的函数。如果您正在执行繁重的 CTFE，并且希望以可能较慢的代码为代价进行更快的编译，请考虑将它们切换为 运行 时间调用。
- DMD（还）不会忽略程序中未使用的符号，这意味着如果您导入模块，模块中的所有函数都会发生代码生成。即使对于选择性进口也是如此。如果您不使用它们，链接器将从生成的可执行文件中 p运行e 函数，但编译器仍然需要时间来编译它们。避免像
import std.algorithm; 或 import std.range; 这样的导入。而是使用特定于包的导入，例如 import std.algorithm.iteration : map;.
如何找出我的d代码的哪一部分编译时间很长？
我尝试使用 valgrind，但方法名称不是很有见地。 87% 的时间花在 <cycle 7>，40% 的时间花在 _D4ddmd5lexer5Lexer4scanMFPS4ddmd6tokens5TokenZv
我正在寻找这样的东西：40% 的时间花在 xy.d 上，其中 80% 的时间花在编译模板 xyz 的各种实例化上，这是一个原因是因为它使用了 memcpy 99% 的时间。
我有兴趣分析 DMD 和 LDC。
由于 D 编译器前端是用 D 编写的，与 C++ 等工具相比，使用传统工具进行分析会相当困难。我在 Linux 上使用 gdb 和 valgrind 等工具以及在 Windows 上使用 VisualD 等工具取得了一些成功，Mac 用户有点 SOL。
您还有五个其他选择：
- 停止尝试在编译器中查找特定函数并转向有关问题的常识（见下文）
- 使用 https://github.com/CyberShadow/DBuildStat 这样的工具。它不会给你你所询问的确切答案，但如果你想让一个大型项目编译得更快，那总比没有好。
- 使用
-v标志尝试查看程序的哪些部分需要一段时间。当然，这是一种非常蛮力的方法，可能会花费您一段时间。 - 修改 DMD 前端的 makefile 以使用
-profile开关。每次你 运行 DMD 你都会得到一个包含很多信息的配置文件。当然，我认为这从未被尝试过。您的里程可能会有所不同。 - 尝试在他们的 Github 问题页面上询问 LDC 团队。 IIRC 他们制作了一个用于分析的补丁版本，用于 Weka.io 代码库。
当我说 turn to common knowledge 时，我的意思是说你的编译速度慢很可能是由于一些常见问题。例如，当 SQL 查询花费的时间太长时，我的第一反应是不会尝试分析 MySQL 服务器代码。以下是几个最常见的问题
- CTFE 虽然可以加快您的 运行 时间，但 很慢 。特别是如果你正在做像
allSatisfy这样的递归模板或者你使用像ctRegex这样的函数。如果您正在执行繁重的 CTFE，并且希望以可能较慢的代码为代价进行更快的编译，请考虑将它们切换为 运行 时间调用。 - DMD（还）不会忽略程序中未使用的符号，这意味着如果您导入模块，模块中的所有函数都会发生代码生成。即使对于选择性进口也是如此。如果您不使用它们，链接器将从生成的可执行文件中 p运行e 函数，但编译器仍然需要时间来编译它们。避免像
import std.algorithm;或import std.range;这样的导入。而是使用特定于包的导入，例如import std.algorithm.iteration : map;.