代码之家 › 专栏 › 技术社区 › Joe Schneider

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

performance compilation build-process

2

Joe Schneider · 技术社区 · 16 年前

作为一名程序员,在很多情况下,我发现我的编译时间比我希望的要慢,我想了解原因并修复它们。特定语言(是的,我使用C/C++)技巧已经被讨论过,我们使用了很多。我也见过 this question 意识到这是相关的。我更感兴趣的是人们使用什么工具来诊断构建过程中的硬件/系统瓶颈。有没有一种标准的方法来证明“磁盘读/写对于我们的构建来说太慢了-我们需要ssd!”或者“反病毒设置正在扼杀我们的构建时间!”等等…

我找到的资源与编译性能诊断没有直接关系:

A TechNet article 关于使用perfmon( 相当很好,接近我想要的)

This IBM link 详细说明了一些perfmon信息,但它并不特定于编译,而且看起来有些过时。

A webpage 具体描述平均磁盘队列长度的诊断

目前,诊断一个缓慢的构建在很大程度上是一门艺术,我选择的工具是:

性能监视器
Process Explorer
Process Monitor
用力推,让机器“试一试”。(基本上是反复试验。)

其他人如何诊断系统级构建性能瓶颈? 我们是否可以列出要监视的perfmon或process explorer统计信息,以及在现代计算机上“可接受”的阈值?

PerfMon:

CPU->%处理器时间

内存->页/秒

磁盘->平均磁盘队列长度

进程资源管理器:

CPU->CPU

磁盘->I/O增量总计

内存->页面错误

2 回复 | 直到 15 年前

1

0

Community Mohan Dere 9 年前

我最近用eclipse和spring解决了一个“构建太慢”的时间问题。对我来说,解决方案是使用vista资源监视器(它识别出cpu峰值,但并不总是很高)和相当多的磁盘活动。然后我用了procmon from Sysinternals 以确定哪些文件被大量访问。

我们构建过程的一部分还包括检查外部maven(二进制文件)存储库,以更新每个构建。我禁用了该检查(这也使我能够完全控制何时更新这些依赖项)。如果您有构建计算机外部的资源,请基准测试访问这些资源所需的时间(源代码管理、maven等)。

因为我现在还停留在32位vista上,所以我决定尝试用700mb的不可寻址内存创建一个ramdisk(pc有4gb,vista只有3.3gb)并将procmon标识的访问量大的文件放在ramdisk上,使用一个很好的技巧来创建驱动器连接来进行移动。对我来说是透明的。详情 see here .

2

0

Ian Ringrose 15 年前

我已经使用Fielon看到了一个C++文件最常打开的头文件,然后使用:

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

不过,这些天我会从一个ramdisk和或ssd开始, 但是打开很多头文件仍然需要大量的cpu时间 .