什么是 c++ 编译性能瓶颈？答案

【问题标题】：What's c++ compiling performance bottle neck?什么是 c++ 编译性能瓶颈？
【发布时间】：2011-06-19 07:00:35
【问题描述】：

当我为我的项目进行全新编译时，其中包括 10 多个开源库。大约需要40分钟。（在普通硬件上）

问题：我的瓶颈到底在哪里？硬盘寻求或CPU Ghz？我认为多核对正确的帮助不大？

--编辑 1--
我的普通硬件 = i3 oc 到 4.0Ghz、8GB 1600Mhz DDR3 和 2tb 西数

--编辑 2--
我的代码 = 10%，库 = 90%，我知道我不必每次都构建所有内容，但我想了解如何提高编译性能，因此在为开发人员购买新电脑时，我会做出更明智的选择。

--编辑 3--
cc = Visual Studio（该死）

【问题讨论】：

这是否意味着您要重新编译所有这些库？您自己的项目有多大？
此外，多核可以提供帮助 - VS 可以同时编译多个文件（对每个文件使用不同的线程），如果我没记错的话，这取决于内核的数量。
当然多核可以提供帮助。
语言是瓶颈！
在这两者中，磁盘几乎总是您最大的瓶颈。并且更容易测试。将您的源文件放在 RAM 磁盘上，看看这会增加多少编译时间，然后再将一大笔钱花在新 CPU 上。

标签： c++ visual-studio compilation

【解决方案1】：

你错了，多核带来了巨大的加速，直到你的硬盘驱动器真正放弃的那一刻:)

通过例子证明：distcc，它带来了分布式构建（我的构建使用大约 20 个并行内核，它实际上受本地预处理阶段的约束）。

至于真正的瓶颈，它与#include 机制有关。带有模块的语言编译得更快...

【讨论】：

【解决方案2】：

40 分钟的构建很可能是由于#include 使用不当造成的（事实上，我会说几乎肯定是 40 分钟）。您正在包含不需要包含的内容，它们可能只需要前向声明。

整理你的代码会产生巨大的差异。我知道它的工作量很大，但你会感到惊讶。在一家公司，我在一家图书馆工作，该图书馆花了 30 多分钟来构建，通过确保需要所有 #include 并添加前向声明而不是 #includeing，在一周多的时间内将其优化为 3 分钟的构建。这个库有超过一百万行的代码给你一个想法......

【讨论】：

好主意！从现在开始我将使用前向声明（只要适用）！ :)

【解决方案3】：

自 VS 2010 起，VS 在编译单个项目时可以选择使用多个内核。它还可以并行编译多个项目。但是，根据我的经验，并行加速似乎并不重要：例如Xcode 更擅长并行构建。

幸运的是，您不必每次都重新构建开源库，对吧？您可以构建它们一次，将 .lib 文件存储在版本控制中，然后将它们用于后续构建。

您是否为自己的代码尝试过预编译的头文件？这可以产生巨大的加速。

【讨论】：

是的，我知道我不必从 CS 第 1 课中构建所有内容。但我只是一个偏执的菜鸟。想要为新版本重新构建一切。
@c2h2：那么你将成为一个偏执的菜鸟，在硬件上浪费金钱，花费大量时间无聊地坐着等待你的代码编译。说真的，利用编译器的预编译头文件支持：它的存在是有原因的，它工作得很好。该库代码不会改变。
@c2h2：您多久构建一次新版本？ 40 分钟的构建时间是否很重要，即使您每天执行一次？（您的意思是不是每个新版本都不同？）
错了。使用 /MP 开关单独编译文件。这没有回答问题。
自 VS 2010 以来，该标志仅受官方支持（在 IDE 中）。

【解决方案4】：

多核编译将在大多数情况下非常有用。

您必须分析您的项目以及每个阶段花费的时间，以确定瓶颈所在。

在典型的大型 c++ 项目中，进程通常受 CPU 限制，然后是磁盘限制。如果反过来，你可能会陷入标题依赖地狱。

实际上有很多方法可以减少项目中的编译时间和依赖性。我所知道的最好的单数参考是 Lakos：

http://www.amazon.com/Large-Scale-Software-Design-John-Lakos/dp/0201633620/ref=sr_1_1?ie=UTF8&qid=1296569079&sr=8-1

这是我读过的最重要/最实用的 C++ 书籍之一。

您通常可以显着减少编译时间（例如，如果您认真对待它，编译时间会加快 40 倍以上），但可能需要大量工作/时间来纠正现有代码库。

【讨论】：

【解决方案5】：

当您从头开始编译时，是的，它需要更长的时间。使用 VS 包含作为项目管理的 40 年历史的 make 技术，只编译第一次运行后需要编译的内容。

也就是说，C++ 的翻译单元模型加上模板的广泛使用可能是一个重要的实际问题。

【讨论】：