logo标签列表

诊断编译/构建缓慢原因的工具

build-processcompilationperformance
4
作为一名程序员，在许多情况下，我发现我的编译时间比我想要的慢，我想了解原因并加以修复。特定语言（是的，我正在使用C / C ++）技巧已经被讨论过，并且我们应用了许多这些技巧。我也看到了这个问题，并意识到它与此有关。我更感兴趣的是人们用什么工具来诊断构建过程中的硬件/系统瓶颈。是否有一种标准方法来证明“磁盘读/写速度对于我们的构建太慢了 - 我们需要SSD！”或“杀死我们的构建时间的反病毒设置！”等等？

我找到的资源与编译性能诊断无直接关系：

  • TechNet文章介绍了如何使用PerfMon（相当不错，接近我想要的）
  • 这个IBM链接详细说明了一些PerfMon信息，但它不是针对编译而特定的，而且似乎有点过时。
  • 一个网页专门描述了平均磁盘队列长度的诊断

目前，诊断缓慢的构建非常依赖经验，我选择的工具是：

其他人如何诊断系统级构建性能瓶颈？我们能否列出要观察的PerfMon或Process Explorer统计信息，并确定现代计算机的“可接受”阈值？

PerfMon:

  • CPU -> 处理器时间的％
  • MEMORY -> 每秒页数
  • DISK -> 平均磁盘队列长度

Process Explorer:

  • CPU -> CPU
  • DISK -> I / O Delta Total
  • MEMORY -> 页面错误
这个问题似乎更适合在serverfault.com上获得更多（也更有用的）答案。系统管理员往往对测量负载和调整机器以适应这些负载有相当丰富的经验。编译器作为你的负载并不是那么重要。 - Jerry Coffin
@Jerry，你说系统管理员可能有这种知识是对的，但这仍然是一个编程问题，而不是系统管理员问题。以后，当其他人在寻找类似主题的帮助时，他们会在SO或SF上查找吗？ - Jay Bazuzi
2个回答
0
我最近解决了Eclipse和Spring的“编译速度太慢”的问题。对我来说，解决方案是使用Vista资源监视器（它能识别CPU峰值但不是一直很高）以及大量的磁盘活动。然后，我使用Sysinternals的Procmon来确定哪些文件被频繁访问。
我们的构建过程中还涉及每次构建都检查外部Maven（二进制文件）存储库是否有更新的步骤。我禁用了该检查（这样我就可以完全控制何时更新这些依赖项）。如果您的资源与构建机器外部相关，请测试一下访问它们所需的时间（源代码控制、maven等）。
由于我目前还在使用32位的Vista系统，我决定尝试创建一个700MB的非可寻址内存Ramdisk，并使用Procmon辨认出来的频繁访问的文件，通过创建驱动器联接的巧妙方法将其移动到Ramdisk上，使得这个操作对我的IDE来说是透明的。具体细节请参考此处。
0

我使用filemon查看C++构建最常打开的头文件，然后使用：

  • “#ifndef检查”，以便头文件只被包含一次
  • 预编译头文件
  • 合并一些小的头文件
  • 通过整理代码减少其他头文件包含的头文件数量。

然而，现在我会从RamDisk和/或SSD开始，但是打开大量的头文件仍然会使用大量CPU时间。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接