Profiling

Question

我有一个大型的基于探地雷达的项目，需要超过30分钟来编译。

在分析了构建过程之后，我注意到许多明显的低效率(对gprbuild的多次调用而不是聚合，过度使用替代文件而不是配置，等等)。我想知道是否有什么方法可以“剖析”构建过程，看看什么花了这么长时间。

特别是，当单个文件发生更改且其中存在错误时，重新编译大约需要5分钟。理论上，应该很快意识到必须重新编译该文件(这是唯一需要重新编译的文件)并启动编译过程，从而快速发现错误。

从冗长的输出来看，仅仅解析用于定义构建的大量gpr文件需要相当长的时间，但是我想知道它大部分时间都花在哪里了。

因此，我的问题是:是否有可能对gprbuild所做的构建进行分析？如果是这样的话，是怎么做的？

Answer 1

从低到高的复杂性：

• 请gprbuild报告更多关于其如何处理标志-vh的详细信息。
• 通过gprbuild运行strace。
• 使用所需的标志重新构建gprbuild，以便使用gprof对其进行分析(但请注意，gprof并不总是说实话)。