在作为程序员的许多情况下，我发现我的编译时间比我想要的慢，我想了解原因并修复它们。已经讨论过特定的语言（是的，我正在使用C / C ++）技巧，我们应用了很多。我也见过this question并意识到它是相关的。我更感兴趣的是人们用什么工具来诊断构建过程中的硬件/系统瓶颈。有没有一种标准的方法来证明“磁盘读/写对我们的构建来说太慢了 - 我们需要SSD！”或者“反病毒设置正在扼杀我们的构建时间！”等......？
我发现的资源，没有一个与编译性能诊断直接相关：
- A TechNet article关于使用PerfMon（相当好，接近我想要的）
- This IBM link详细说明了一些PerfMon信息，但它并不特定于编译并且看起来有些过时。
- A webpage专门描述avg磁盘队列长度的诊断
目前，诊断慢速构建非常具有艺术性，我选择的工具是：
其他人如何诊断系统级构建性能瓶颈？ 我们是否可以提供一个PerfMon或Process Explorer统计数据列表，以便在现代机器上获得“可接受”的阈值？
性能监视器：
- CPU - ＆gt;处理器时间的百分比
- 记忆 - ＆gt; Page / sec
- DISK - ＆gt;平均。磁盘队列长度
Process Explorer：
- CPU - ＆gt; CPU
- DISK - ＆gt; I / O Delta Total
- 记忆 - ＆gt;页面错误
答案 0 :(得分：0)
我最近解决了Eclipse和Spring的“太慢构建”时间问题。对我来说，解决方案是使用Vista资源监视器（它确定CPU尖峰但不是一直很高）和相当多的磁盘活动。然后我使用来自Sysinternals的Procmon来确定哪些文件被大量访问。
我们的构建过程的一部分还涉及检查外部Maven（二进制文件）存储库以获取每次构建的更新。我禁用了该检查（这也使我能够完全控制何时更新这些依赖项）。如果你有构建机器外部的资源，那么基准测试访问它们需要多长时间（源代码控制，maven等）。
由于我现在停留在32位Vista上，我决定尝试创建一个带有700MB非可寻址内存的Ramdisk（PC有4GB，Vista仅暴露3.3GB）并将访问量很大的文件放在已识别的位置通过Procmon在Ramdisk上使用一个很好的技巧来创建驱动器连接，使该移动对我的IDE透明。有关详细信息see here。
答案 1 :(得分：0)
我已经使用filemon来查看C ++构建最常打开然后使用的头文件：
但是现在我会从RamDisk和/或SSD开始，但是开放的头文件仍然会占用大量的CPU时间。