测量构建时间以识别瓶颈
我正在努力改进一些项目的构建。我已经相当显着地缩短了构建时间，而且我现在认为瓶颈更加微妙。
构建使用 GNU 风格的 makefile。我生成一系列依赖文件 (.d) 并将它们包含在 makefile 中，否则就没有什么奇怪的事情发生（例如，没有预编译头或其他缓存机制）。
在 32 核 sparc ultra 上构建大约需要 95 秒，并行运行 16 个线程。构建运行时空闲时间徘徊在 80% 左右，内核时间徘徊在 8-10% 之间。我将代码放在 /tmp 中，但大多数编译器支持文件都是 NFS 挂载的，我相信这可能会造成性能瓶颈。
有哪些工具可用于测量和分析追踪这类问题？
I'm working on improving the build for a few projects. I've improved build times quite significantly, and I'm at a point now where I think the bottlenecks are more subtle.
The build uses GNU style makefiles. I generate a series of dependency files (.d) and include them in the makefile, otherwise there's nothing fancy going on (eg, no pre-compiled headers or other caching mechanisms).
The build takes about 95 seconds on a 32-core sparc ultra, running with 16 threads in parallel. Idle time hovers around 80% while the build runs, with kernel time hovering between 8-10%. I put the code in /tmp, but most of the compiler support files are NFS mounted and I believe this may be creating a performance bottleneck.
What tools exist for measuring & tracking down these sorts of problems?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
根据我自己的经验，编译C/C++代码需要通过C预处理器读取大量的头文件。我曾经遇到过需要花费超过 50% 的 g++ 运行时间来生成完整翻译单元的情况。
正如您提到的，编译时它空闲了 80%，那么它必须等待 I/O。 iostat 和 DTrace 将是一个很好的起点。
From my own experience, compiling C/C++ code requires reading a lot of header files by C preprocessor. I've experienced situations when it took more than 50% of g++ run-time to generate a complete translation unit.
As you mentioned that it idles 80% when compiling it must be waiting for I/O then.
iostatand DTrace would be a good starting point.