joh*_*hnc 132 c# compilation visual-studio
我们的编译时间非常慢,在双核2GHz,2G Ram机器上可能需要20多分钟.
这很大程度上是由于我们的解决方案的规模已经发展到70多个项目,以及VSS,当你拥有大量文件时,它本身就是瓶颈.(不幸的是,交换VSS不是一个选项,所以我不希望它下降到VSS bash)
我们正在考虑合并项目.我们还在寻找多种解决方案,以便为应用程序的每个元素实现更大的关注点分离和更快的编译时间.我可以看到这将成为一个DLL地狱,因为我们试图保持同步.
我很想知道其他团队如何处理这个扩展问题,当你的代码库达到一个临界质量时你会怎么做,你正在看着状态栏传递编译消息的一半时间.
更新 我忽略了这是一个C#解决方案.感谢所有的C++建议,但是我已经有几年了,因为我不得不担心标题.
编辑:
到目前为止有很好的建议(不是说下面没有其他好的建议,只是帮助了什么)
仍然没有通过编译扯皮,但每一点都有帮助.
Orion在评论中确实提到仿制药也可能有一个游戏.从我的测试来看,似乎确实有最小的性能损失,但不足以确定 - 由于光盘活动,编译时间可能不一致.由于时间限制,我的测试没有包含与实时系统中出现的一样多的泛型或代码,因此可能会累积.我不会避免在它们应该被使用的地方使用泛型,只是为了编译时的性能
替代方法
我们正在测试在新解决方案中构建应用程序新领域的实践,根据需要导入最新的dll,当我们对它们感到满意时,将它们集成到更大的解决方案中.
我们也可以通过创建临时解决方案来对现有代码执行相同的操作,这些解决方案仅封装我们需要处理的区域,并在重新集成代码后将它们丢弃.我们需要权衡重新整合这些代码所需的时间与我们获得的时间,因为没有Rip Van Winkle喜欢在开发过程中快速重新编译的经验.
Nat*_*ate 74
Chromium.org团队列出了几个加速构建的选项(此时大约是页面的一半):
按加速顺序递减:
- 安装Microsoft修补程序935225.
- 安装Microsoft修补程序947315.
- 使用真正的多核处理器(即Intel Core Duo 2;而不是Pentium 4 HT).
- 使用3个并行构建.在Visual Studio 2005中,您将在工具>选项...>项目和解决方案>构建和运行>最大并行项目构建数中找到该选项.
- 禁用.ilk,.pdb,.cc,.h文件的防病毒软件,仅在修改时检查病毒.禁用扫描源所在的目录.不要做任何愚蠢的事.
- 在第二个硬盘驱动器上存储和构建Chromium代码.它不会真正加速构建,但至少当你进行gclient同步或构建时,你的计算机将保持响应.
- 定期对硬盘进行碎片整理.
- 禁用虚拟内存.
Gon*_*ing 58
对于本地开发版本,我们创建了一个Visual Studio外接改变Project references到DLL references和卸载不需要的项目(和选项切换回的课程).
我们的构建现在只需几秒钟,我们一次只处理几个项目.我们还可以在链接到调试DLL时调试其他项目.该工具通常需要10-30秒才能进行大量更改,但您不必经常这样做.
我做的交易(在下面的评论中)是,如果获得足够的兴趣,我会将插件发布到开源.4年后它只有44票(而Visual Studio现在有两个后续版本),所以它目前是一个低优先级的项目.
小智 24
我在21个项目和1/2万LOC的解决方案上遇到了类似的问题.最大的不同是硬盘速度越来越快.从性能监视器'平均.磁盘队列会在笔记本电脑上显着跳跃,表明硬盘是瓶颈.
以下是总重建时间的一些数据......
1)笔记本电脑,Core 2 Duo 2GHz,5400 RPM驱动器(不确定缓存.是标准的Dell inspiron).
重建时间= 112秒.
2)桌面(标准版),Core 2 Duo 2.3Ghz,单个7200RPM驱动器8MB缓存.
重建时间= 72秒.
3)Desktop Core 2 Duo 3Ghz,单个10000 RPM WD Raptor
重建时间= 39秒.
10,000 RPM驱动器不容低估.构建显着更快,加上其他所有内容,如显示文档,使用文件浏览器显然更快.通过加快代码构建运行周期,可以大大提高生产力.
鉴于开发商的薪水花哪些公司是疯了,他们多少可以买废用相同的电脑equiping它们作为接待员使用.
小智 16
对于C#.NET构建,您可以使用.NET Demon.它是一种接管Visual Studio构建过程以使其更快的产品.
它通过分析您所做的更改来完成此操作,并仅构建您实际更改的项目,以及实际依赖您所做更改的其他项目.这意味着如果您只更改内部代码,则只需要构建一个项目.
jde*_*tor 14
关闭防病毒软件.它增加了编译时间.
aku*_*aku 12
使用分布式编译.Xoreax IncrediBuild可以将编译时间缩短到几分钟.
我在一个庞大的C\C++解决方案中使用它,通常需要5-6个小时来编译.IncrediBuild帮助将这个时间减少到15分钟.
小智 11
有关将Visual Studio编译时间缩短到几秒的说明
遗憾的是,Visual Studio不够智能,无法将程序集的界面更改与无关紧要的代码体更改区分开来.这一事实与大型交织解决方案相结合,有时可以在每次更改单行代码时创建一个完美的不必要的"完整构建"风暴.
克服此问题的策略是禁用自动引用树构建.要做到这一点,使用"配置管理器"(编译/配置管理器...然后在活动解决方案配置下拉列表中,选择"新建")创建一个名为"ManualCompile"从调试配置副本,新构建配置,但做不选中"创建新项目配置"复选框.在这个新的构建配置中,取消选中每个项目,以便它们不会自动构建.点击"关闭"保存此配置.此新构建配置将添加到您的解决方案文件中.
您可以通过IDE屏幕顶部的构建配置下拉列表(通常显示"Debug"或"Release")来从一个构建配置切换到另一个构建配置.实际上,这个新的ManualCompile构建配置将使"构建解决方案"或"重建解决方案"的构建菜单选项无效.因此,当您处于ManualCompile模式时,必须手动构建要修改的每个项目,这可以通过在解决方案资源管理器中右键单击每个受影响的项目,然后选择"构建"或"重建"来完成.你应该看到你的整体编译时间现在只有几秒钟.
要使此策略起作用,必须使AssemblyInfo和GlobalAssemblyInfo文件中的VersionNumber在开发人员的计算机上保持静态(当然不是在发布版本期间),并且不要对DLL进行签名.
使用这种ManualCompile战略的一个潜在风险是,开发人员可能会忘记编译所需的项目,当他们开始调试程序,他们得到意想不到的结果(无法附加调试器,文件找不到,等).为避免这种情况,最好使用"Debug"构建配置来编译更大的编码工作,并且仅在单元测试期间使用ManualCompile构建配置或进行范围有限的快速更改.
我们的主要解决方案中有80多个项目,需要大约4到6分钟才能构建,具体取决于开发人员正在使用哪种机器.我们认为这太长了:对于每一次测试,它都会真正吞噬你的FTE.
那么如何加快构建时间呢？正如您似乎已经知道的那样,真正损害构建时间的项目数量.当然,我们不想摆脱所有项目,只需将所有源文件合并为一个.但是我们有一些项目可以合并:由于解决方案中的每个"知识库项目"都有自己的单元测试项目,我们只需将所有单元测试项目合并为一个全局单元测试项目.这减少了大约12个项目的项目数量,并以某种方式节省了40%的时间来构建整个解决方案.
我们正在考虑另一种解决方案.
您是否也尝试使用新项目设置新的(第二)解决方案？第二个解决方案应该只使用解决方案文件夹合并所有文 因为您可能会惊讶地看到新解决方案的构建时间 - 只需一个项目.
但是,使用两种不同的解决方案需要仔细考虑.开发人员可能倾向于在第二个解决方案中实际工作,而完全忽略第一个解决方案.由于70多个项目的第一个解决方案将是处理对象层次结构的解决方案,因此这应该是构建服务器应运行所有单元测试的解决方案.因此,Continous Integration的服务器必须是第一个项目/解决方案.你必须维护你的对象层次结构.
只有一个项目的第二个解决方案(将更快地构建)将是所有开发人员将完成测试和调试的项目.你必须照顾他们看看构建服务器!如果有什么破坏必须修复.
我最初在这里发布了这个回复:https: //stackoverflow.com/questions/8440/visual-studio-optimizations#8473 您可以在该页面上找到许多其他有用的提示.
如果您使用的是Visual Studio 2008,则可以使用/ MP标志进行编译,以并行构建单个项目.我已经读过,这也是Visual Studio 2005中的一个未记录的功能,但从未尝试过.
您可以使用/ M标志并行构建多个项目,但这通常已设置为计算机上可用核心的数量,但这仅适用于我认为的VC++.
小智 6
我注意到这个问题已经很久了,但今天这个话题仍然很有意思.同样的问题最近让我感到困惑,最能提高构建性能的两件事是:(1)使用专用(和快速)磁盘进行编译;(2)对所有项目使用相同的输出文件夹,并在项目中将CopyLocal设置为False引用.
一些额外的资源:
一些分析工具:
tools-> options-> VC++项目设置 - > Build Timing = Yes将告诉你每个vcproj的构建时间.
将/Bt开关添加到编译器命令行以查看每个CPP文件花了多少
使用/showIncludes捕捉嵌套包含(头文件包含其他头文件),并查看哪些文件可以通过使用前置声明节省了大量的IO.
这将通过消除依赖性和性能损害来帮助您优化编译器性能.
小智 5
在花钱购买更快的硬盘之前,尝试完全在RAM磁盘上构建项目(假设你有备用的RAM).您可以在网上找到各种免费的RAM磁盘驱动程序.您将找不到比RAM磁盘更快的任何物理驱动器,包括SSD.
在我的情况下,使用RAM磁盘,在带有Incredibuild的7200 RPM SATA驱动器上花费5分钟构建6核i7的项目仅减少了大约15秒.考虑到需要重新复制到永久存储和丢失工作的可能性,15秒不足以激励使用RAM磁盘,并且可能没有太多动力在高RPM或SSD驱动器上花费数百美元.
小增益可能表明构建受CPU限制或Windows文件缓存相当有效,但由于两个测试都是从未缓存文件的状态完成的,因此我严重依赖于CPU绑定编译.
根据您编制的实际代码,您的里程可能会有所不同 - 所以请不要犹豫,进行测试.
| 归档时间： |
|
| 查看次数： |
85874 次 |
| 最近记录： |