编译器处理包含保护头的开销有多大？
为了加速大型源文件的编译，修剪翻译单元中使用的标头数量是否更有意义，或者编译代码的成本是否远远超过处理包含保护所需的时间标头？
如果后者是真的，那么工程工作最好花在创建更多、轻量级的标头上，而不是更少。
那么，现代编译器需要多长时间才能处理有效包含保护的标头？在什么时候包含此类标头会影响编译性能？
（与此问题相关）
To speed up the compilation of a large source file does it make more sense to prune back the sheer number of headers used in a translation unit, or does the cost of compiling code far outweigh the time it takes to process-out an include-guarded header?
If the latter is true an engineering effort would be better spent creating more, lightweight headers instead of less.
So how long does it take for a modern compiler to handle a header that is effectively include-guarded out? At what point would the inclusion of such headers become a hit on compilation performance?
(related to this question)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
前几天我读到了有关此问题的常见问题解答...首先，编写正确的标头，即包含您使用的所有标头，并且不依赖于未记录的依赖项（可能会发生变化）。
其次，编译器现在通常会识别包含保护，因此它们相当高效。但是，您仍然需要打开大量文件，这可能会成为大型项目的负担。一个建议是这样做：
头文件：
现在要在源文件中使用标头，请添加额外的
#ifndef：源文件中的噪音会更大，并且您需要可预测的包含保护名称，但是您可能会避免很多这样的包含指令。
I read an FAQ about this the other day... first off, write the correct headers, i.e. include all headers that you use and don't depend on undocumented dependencies (which may and will change).
Second, compilers usually recognize include guards these days, so they're fairly efficient. However, you still need to open a lot of files, which may become a burden in large projects. One suggestion was to do this:
Header file:
Now to use the header in your source file, add an extra
#ifndef:It'll be noisier in the source file, and you require predictable include guard names, but you could potentially avoid a lot of include-directives like that.
假设 C/C++，头文件的简单重新编译对于大型系统（数百个文件）来说是非线性扩展的，因此如果编译性能是一个问题，很可能就是这个问题。至少除非您尝试在 20 世纪 80 年代的 PC 上编译一百万行源文件...
预编译头文件适用于大多数编译器，但通常需要特定的配置和管理来处理非系统头文件，这并不是每个项目做。
例如，请参见：
http://www.cygnus-software.com/papers/precompiledheaders。 html
“我的项目的构建时间现在是以前的 15%！”
除此之外，您还需要查看以下技术：
http://www.amazon.com/exec/obidos/ASIN/0201633620/qid%3D990165010/002-0139320-7720029
或者使用干净的、非基于标头的接口将系统拆分为多个部分在它们之间，比如 .NET 组件。
Assuming C/C++, simple recompilation of header files scales non-linearly for a large system (hundreds of files), so if compilation performance is an issue, it is very likely down to that. At least unless you are trying to compile a million line source file on a 1980s era PC...
Pre-compiled headers are available for most compilers, but generally take specific configuration and management to work on non system-headers, which not every project does.
See for example:
http://www.cygnus-software.com/papers/precompiledheaders.html
'Build time on my project is now 15% of what it was before!'
Beyond that, you need to look at the techniques in:
http://www.amazon.com/exec/obidos/ASIN/0201633620/qid%3D990165010/002-0139320-7720029
Or split the system into multiple parts with clean, non-header-based interfaces between them, say .NET components.
答案：
它可能非常昂贵！
我发现一篇文章，其中有人对此处解决的问题进行了一些测试，并且惊讶地发现您可以增加编译如果您正确编写包含防护，则 MSVC 下的时间至少增加一个数量级：
http://www.bobarcher.org/software/include/index.html
结果中最令人惊讶的是，在 MSVC 2008 下编译的测试文件从 5.48 秒缩短到 0.13 秒给定正确的包含防护方法。
The answer:
It can be very expensive!
I found an article where someone had done some testing of the very issue addressed here, and am astonished to find you can increase your compilation time under MSVC by at least an order of magnitude if you write your include guards properly:
http://www.bobarcher.org/software/include/index.html
The most astonishing line from the results is that a test file compiled under MSVC 2008 goes from 5.48s to 0.13s given the right include guard methodology.