profiling - 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 时，您都会获得一个包含大量信息的配置文件。当然，我认为这还没有被尝试过。您的里程可能会有所不同。
5. 尝试在 LDC 团队的 Github 问题页面上询问此问题。 IIRC 他们制作了一个用于分析的修补版本，用于 Weka.io 代码库。

当我说转向常识时，我的意思是说您的编译缓慢可能是由于一些常见问题造成的。例如，当 SQL 查询花费太长时间时，我的第一 react 不是尝试分析 MySQL 服务器代码。以下是一些最常见的问题

1. CTFE 虽然可以加快运行时间，但它很慢。特别是如果您使用 allSatisfy 等递归模板或使用 ctRegex 等函数。如果您正在执行繁重的 CTFE，并且希望以可能较慢的代码为代价实现更快的编译，请考虑将它们切换为运行时调用。
2. DMD(还)不会忽略程序中未使用的符号，这意味着如果导入模块，模块中的所有函数都会发生代码生成。即使对于选择性进口也是如此。如果不使用它们，链接器将从生成的可执行文件中删除这些函数，但编译器仍然需要时间来编译它们。避免像 import std.algorithm; 或 import std.range; 这样的导入。相反，请使用特定于包的导入，例如 import std.algorithm.iteration : map;。