减少构建时间 [英] Reducing build times
问题描述
寻找加速构建的技巧...
我们有一个应用程序，大约有970个我们自己的各种类型的b / b $ b $加上一个公平的例程数量。在过去的一年中，
编译/链接时间在PC（MFC开发工作室6）和
linux上一直在减慢。 PC上的链接时间似乎取决于RAM - 一台新的台式机
，2Gb内存编译和链接速度明显快于具有1/2 Gb的三台b
岁笔记本电脑RAM但处理器速度相同。
在过去一年左右的时间里，我们一直在使用更多的模板和更多的STL。
我们还有更多的课程，但我不认为项目的大小
完全解释了减速。
我们使用的技巧：
- 在PC上，预编译的头文件包括经常使用的东西，比如
stingray include files;在Unix上这被绕过了（虽然我明白了
gcc现在支持吗？）
- 我们适当地减少了级联包含文件（成员变量
是通常指针，除非明智地选择不这样做）
- 我已经开始通过pimpl进一步隐藏一些实现，特别是在完全对话支持类所使用的
对话框中否则
无论如何需要
问：还有其他技巧吗？
问：可以正确使用命名空间帮助？
问：关于构建时间，stl或模板是否存在问题？
问：我们还没有真正意识到需要将项目拆分为
图书馆。这有用吗（如果有，为什么？）
Stuart
Looking for tricks for speeding up builds...
We have an application with about 970 of our own classes of various
sizes plus a fair number of routines. Over the past year the
compile/link time has been slowing down on PC (MFC dev studio 6) and on
linux. Link time on PC seems to depend on RAM - a new desktop machine
with 2Gb of RAM compiles and links significantly faster than a three
year old laptop with 1/2 Gb of RAM but same processor speed.
Over the past year or so we''ve been using more templates and more STL.
We also have more classes, but I don''t think the size of the project
fully accounts for the slowdown.
Tricks we use:
- On PC, precompiled header file includes often used things like
stingray include files; on Unix this is bypassed (although I understand
gcc now supports it?)
- We appropriately minimize cascading include files (member variables
are typically pointers, except where judiciously chosen not to be)
- I''ve started hiding some implementations further by pimpl, especially
dialogs used where the full dialog support classes aren''t otherwise
needed anyway
Q: Are there any other tricks?
Q: Can proper use of namespaces help?
Q: Is there an issue with stl or templates with respect to build times?
Q: We haven''t really seen the need to split the project up into
libraries. Can this help (and if so, why?)
Stuart
推荐答案
Stuart MacMartin写道：
Stuart MacMartin wrote:
寻找加速构建的技巧...
问：还有其他技巧吗？
前向班级申报。您可以转发声明除数据成员之外的所有类
。还返回值传递的值类型和类型
值到函数。
问：正确使用命名空间有帮助吗？
别看怎么样。
问：关于构建时间，stl或模板是否存在问题？
当然。模板是''标题''！模板需要包含在内，
解析并实例化。
问：我们还没有真正意识到需要将项目拆分为
库。这有用吗（如果有，为什么？）
Looking for tricks for speeding up builds... Q: Are there any other tricks?
Forward declaration of classes. You can forward declare all classes
except for data members. Also return value types and types passed by
value to functions.
Q: Can proper use of namespaces help?
Don''t see how.
Q: Is there an issue with stl or templates with respect to build times?
Of course. Templates are ''header only''! Templates need to be included,
parsed, and instantiated.
Q: We haven''t really seen the need to split the project up into
libraries. Can this help (and if so, why?)
如果可以拆分它。不是为模块化而设计的代码往往是整合和混合的。顺便说一句，这个案例中最好的书仍然是John Lakos的'大规模C ++软件设计'。
If you can split it. Code that is not designed for modularity tends to
be momolithic and intermingled. BTW, the best book in this case still
is John Lakos ''Large-Scale C++ Software Design''.
" Stuart MacMartin" < sj*@igs.net>在消息中写道
news：11 ********************** @ f14g2000cwb.googlegr oups.com ...
"Stuart MacMartin" <sj*@igs.net> wrote in message
news:11**********************@f14g2000cwb.googlegr oups.com...
寻找加速构建的技巧......
我们有一个应用程序，大约有970个我们自己的各种类型的类，加上相当多的例程。在过去的一年中，在PC（MFC开发工作室6）和
linux上，编译/链接时间一直在减慢。 PC上的链接时间似乎取决于RAM - 一台新的桌面计算机，带有2Gb的RAM编译和连接速度明显快于具有1/2 Gb RAM但处理器速度相同的三年前的笔记本电脑。 br />
在过去一年左右的时间里，我们一直在使用更多的模板和更多的STL。
我们还有更多的课程，但我不认为项目的大小
完全解释减速。
我们使用的技巧：
- 在PC上，预编译的头文件包括经常使用的东西，如st /ray黄貂鱼包含文件;在Unix上这被绕过了（虽然我明白
gcc现在支持它吗？）
- 我们适当地最小化级联包含文件（成员变量
通常是指针，除非明智地选择不是）
- 我已经开始通过pimpl进一步隐藏一些实现，特别是
对话框，无论如何都不需要完整的对话支持类
问：还有其他技巧吗？
问：正确使用名称空间有帮助吗？
问：构建时间是否存在stl或模板问题？
问：我们还没有真的看到需要将项目分成
库。这有用吗（如果有，为什么？）
Stuart
Looking for tricks for speeding up builds...
We have an application with about 970 of our own classes of various
sizes plus a fair number of routines. Over the past year the
compile/link time has been slowing down on PC (MFC dev studio 6) and on
linux. Link time on PC seems to depend on RAM - a new desktop machine
with 2Gb of RAM compiles and links significantly faster than a three
year old laptop with 1/2 Gb of RAM but same processor speed.
Over the past year or so we''ve been using more templates and more STL.
We also have more classes, but I don''t think the size of the project
fully accounts for the slowdown.
Tricks we use:
- On PC, precompiled header file includes often used things like
stingray include files; on Unix this is bypassed (although I understand
gcc now supports it?)
- We appropriately minimize cascading include files (member variables
are typically pointers, except where judiciously chosen not to be)
- I''ve started hiding some implementations further by pimpl, especially
dialogs used where the full dialog support classes aren''t otherwise
needed anyway
Q: Are there any other tricks?
Q: Can proper use of namespaces help?
Q: Is there an issue with stl or templates with respect to build times?
Q: We haven''t really seen the need to split the project up into
libraries. Can this help (and if so, why?)
Stuart
你可以为你的编译器弹出一个pragma来说''build this只有一次''。
虽然这不是很便携，但在VS6中它可以实现：
#pragma一次
Allan
you can pop a pragma for your compiler to say ''build this class only once''.
This is not very portable though, in VS6 the follwing does it:
#pragma once
Allan
我们使用
#if！定义（FILE_H）在我们的包含文件中进行等效保护
＃定义FILE_H
...
#endif
也适用于cascaded includes我的意思是我们不会在包含文件中包含其他文件
，除非我们真的必须提到该类
的值。我们尝试尽可能在包含文件中使用类
的前向声明。
Stuart
We do equivalent protection within our include files using
#if !defined(FILE_H)
#define FILE_H
...
#endif
Also for "cascaded includes" I meant we don''t include other files
in the include files unless we really have to mention that class
by value. We try to use forward declarations of classes
in the include files wherever possible.
Stuart
这篇关于减少构建时间的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
