首页 文章

Visual Studio 2005上的编译时间非常慢

提问于
浏览
132

我们的编译时间非常慢,在双核2GHz,2G Ram机器上可能需要20分钟 .

这很大程度上是由于我们的解决方案已经发展到70个项目,以及VSS,当你拥有大量文件时,它本身就是一个瓶颈 . (不幸的是,交换VSS不是一个选项,所以我不希望它下降到VSS bash)

我们正在考虑合并项目 . 我们还在寻找多种解决方案,以便为应用程序的每个元素实现更大的关注点分离和更快的编译时间 . 我可以看到这将成为一个DLL地狱,因为我们试图保持同步 .

我很想知道其他团队如何处理这个扩展问题,当你的代码库达到一个临界质量时你会怎么做,你正在看着状态栏传递编译消息的一半时间 .

UPDATE 我忽略了这是一个C#解决方案 . 感谢所有的C建议,但它不得不担心 Headers .

EDIT:

到目前为止有很好的建议(不是说下面没有其他好的建议,只是帮助了什么)

  • 新的3GHz笔记本电脑 - 失去使用率的力量在对管理层表示怀疑时起到了作用

  • 在编译期间禁用防病毒
    编译过程中来自VSS(实际上是网络)

  • 'Disconnecting'我可能会让我们完全删除VS-VSS集成并坚持使用VSS UI

仍然没有通过编译扯皮,但每一点都有帮助 .

Orion在评论中确实提到仿制药也可能有一个游戏 . 从我的测试来看,似乎确实有最小的性能损失,但不足以确定 - 由于光盘活动,编译时间可能不一致 . 由于时间限制,我的测试没有包含与实时系统中出现的一样多的泛型或代码,因此可能会累积 . 我不会避免在它们应该被使用的地方使用泛型,只是为了编译时的性能

WORKAROUND

我们正在测试在新解决方案中构建应用程序新领域的实践,根据需要导入最新的dll,当我们对它们感到满意时,将它们集成到更大的解决方案中 .

我们也可以通过创建临时解决方案来对现有代码执行相同的操作,这些解决方案仅封装我们需要处理的区域,并在重新集成代码后将它们丢弃 . 我们需要权衡重新整合这些代码所需的时间与我们获得的时间,因为没有Rip Van Winkle喜欢在开发过程中快速重新编译的经验 .

30 回答

  • 16

    Chromium.org团队列出了accelerating the build的几个选项(此时大约在页面的一半):

    按加速顺序递减:安装Microsoft修补程序935225.安装Microsoft修补程序947315.使用真正的多核处理器(即Intel Core Duo 2;而不是Pentium 4 HT) . 使用3个并行构建 . 在Visual Studio 2005中,您将在工具>选项...>项目和解决方案>构建和运行>最大并行项目构建数中找到该选项 . 禁用.ilk,.pdb,.cc,.h文件的防病毒软件,仅在修改时检查病毒 . 禁用扫描源所在的目录 . 不要做任何愚蠢的事 . 在第二个硬盘驱动器上存储和构建Chromium代码 . 它不会真正加速构建,但至少当你进行gclient同步或构建时,你的计算机将保持响应 . 定期对硬盘进行碎片整理 . 禁用虚拟内存 .

  • 1

    我们在一个解决方案中有近100个项目,开发时间只有几秒钟:)

    对于本地开发版本,我们创建了一个Visual Studio Addin,它将 Project references 更改为 DLL references 并卸载不需要的项目(当然还有一个选项可以将它们切换回来) .

    • 构建我们的整个解决方案一次

    • 卸载我们当前没有处理的项目,并更改DLL引用的所有项目引用 .

    • 在签入之前,将所有引用从DLL更改回项目引用 .

    我们的构建现在只需几秒钟,我们一次只处理几个项目 . 我们还可以在链接到调试DLL时调试其他项目 . 该工具通常需要10-30秒才能进行大量更改,但您不必经常这样做 .

    2015年5月更新

    我做的交易(在下面的评论中)是,如果获得足够的兴趣,我会将插件发布到开源 . 4年后它只有44票(而Visual Studio现在有两张后续版本),因此它目前是一个低优先级的项目 .

  • 1

    我在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驱动器不容低估 . 构建显着更快,加上其他所有内容,如显示文档,使用文件浏览器显然更快 . 通过加快代码构建运行周期,可以大大提高 生产环境 力 .

    考虑到公司在开发人员工资上花费了多少钱,他们可以浪费多少钱来为他们配备与接待员使用相同的PC .

  • 7

    对于C#.NET构建,您可以使用.NET Demon . 它是一种接管Visual Studio构建过程以使其更快的产品 .

    它通过分析您所做的更改来完成此操作,并仅构建您实际更改的项目,以及实际依赖您所做更改的其他项目 . 这意味着如果您只更改内部代码,则只需要构建一个项目 .

  • 7

    关闭防病毒软件 . 它增加了编译时间 .

  • 2

    使用分布式编译 . Xoreax IncrediBuild可以将编译时间缩短到几分钟 .

    我在一个庞大的C \ C解决方案上使用它,通常需要5-6个小时来编译 . IncrediBuild帮助将这个时间减少到15分钟 .

  • 6

    有关将Visual Studio编译时间缩短到几秒的说明

    遗憾的是,Visual Studio不够智能,无法将程序集的界面更改与无关紧要的代码体更改区分开来 . 这一事实与大型交织解决方案相结合,有时可以在每次更改单行代码时创建一个完美的不必要的“完整构建”风暴 .

    克服此问题的策略是禁用自动引用树构建 . 要执行此操作,请使用“Configuration Manager”(构建/配置管理器...然后在“活动解决方案配置”下拉列表中选择“新建”)以创建名为“ManualCompile”的新构建配置,该配置从Debug配置进行复制,但是不选中“创建新项目配置”复选框 . 在这个新的构建配置中,取消选中每个项目,以便它们不会自动构建 . 点击“关闭”保存此配置 . 此新构建配置将添加到您的解决方案文件中 .

    您可以通过IDE屏幕顶部的构建配置下拉列表(通常显示“Debug”或“Release”)来从一个构建配置切换到另一个构建配置 . 实际上,这个新的ManualCompile构建配置将使“构建解决方案”或“重建解决方案”的构建菜单选项无效 . 因此,当您处于ManualCompile模式时,必须手动构建要修改的每个项目,这可以通过在解决方案资源管理器中右键单击每个受影响的项目,然后选择“构建”或“重建”来完成 . 你应该看到你的整体编译时间现在只有几秒钟 .

    要使此策略起作用,必须使AssemblyInfo和GlobalAssemblyInfo文件中的VersionNumber在开发人员的计算机上保持静态(当然不是在发布版本期间),并且不要对DLL进行签名 .

    使用此ManualCompile策略的潜在风险是开发人员可能忘记编译所需的项目,并且当他们启动调试器时,他们会得到意外的结果(无法附加调试器,找不到文件等) . 为避免这种情况,最好使用“Debug”构建配置来编译更大的编码工作,并且仅在单元测试期间使用ManualCompile构建配置或进行范围有限的快速更改 .

  • 1

    如果这是C或C,并且您没有使用预编译的头文件,那么您应该这样做 .

  • 5

    我们的主要解决方案中有80个项目,需要大约4到6分钟才能构建,具体取决于开发人员正在使用哪种机器 . 我们认为这太长了:对于每一次测试,它都会真正吞噬你的FTE .

    那么如何变得更快 Build 时间?正如您似乎已经知道的那样,真正损害构建时间的项目数量 . 当然,我们不想摆脱所有项目,只需将所有源文件合并为一个 . 但是我们有一些项目可以合并:由于解决方案中的每个“知识库项目”都有自己的单元测试项目,我们只需将所有单元测试项目合并为一个全局单元测试项目 . 这减少了大约12个项目的项目数量,并以某种方式节省了40%的时间来构建整个解决方案 .

    我们正在考虑另一种解决方案 .

    您是否也尝试使用新项目设置新的(第二)解决方案?第二个解决方案应该只使用解决方案文件夹合并所有文因为您可能会惊讶地看到新解决方案的构建时间 - 只需一个项目 .

    但是,使用两种不同的解决方案需要仔细考虑 . 开发人员可能倾向于在第二个解决方案中实际工作,而完全忽略第一个解决方案 . 由于70个项目的第一个解决方案将是处理对象层次结构的解决方案,因此这应该是构建服务器应运行所有单元测试的解决方案 . 因此,Continous Integration的服务器必须是第一个项目/解决方案 . 你必须维护你的对象层次结构 .

    只有一个项目的第二个解决方案(将更快地构建)将是所有开发人员将完成测试和调试的项目 . 你必须照顾他们看看构建服务器!如果有什么破坏必须修复 .

  • 23

    确保您的引用是Project引用,而不是直接引用到库输出目录中的DLL .

    此外,将这些设置为不在本地复制,除非绝对必要(主EXE项目) .

  • 5

    我最初在这里发布了这个回复:https://stackoverflow.com/questions/8440/visual-studio-optimizations#8473您可以在该页面上找到许多其他有用的提示 .

    如果您使用的是Visual Studio 2008,则可以使用/ MP标志进行编译,以并行构建单个项目 . 我已经读过,这也是Visual Studio 2005中的一个未记录的功能,但从未尝试过 .

    您可以使用/ M标志并行构建多个项目,但这通常已设置为计算机上可用核心的数量,但这仅适用于我认为的VC .

  • 1

    我注意到这个问题已经很久了,但今天这个话题仍然很有意思 . 同样的问题最近让我感到困惑,最能提高构建性能的两件事是:(1)使用专用(和快速)磁盘进行编译;(2)对所有项目使用相同的输出文件夹,并在项目中将CopyLocal设置为False引用 .

    一些额外的资源:

  • 1

    一些分析工具:

    tools-> options-> VC项目设置 - > Build Timing = Yes将告诉你每个vcproj的构建时间 .

    添加 /Bt 切换到编译器命令行以查看每个CPP文件花了多少

    使用 /showIncludes 来捕获嵌套的包含(包含其他头文件的头文件),并查看哪些文件可以通过使用前向声明来节省大量IO .

    这将通过消除依赖性和性能损害来帮助您优化编译器性能 .

  • 3

    在花钱购买更快的硬盘之前,尝试完全在RAM磁盘上构建项目(假设你有备用的RAM) . 您可以在网上找到各种免费的RAM磁盘驱动程序 . 您将找不到比RAM磁盘更快的任何物理驱动器,包括SSD .

    在我的情况下,使用RAM磁盘,在带有Incredibuild的7200 RPM SATA驱动器上花费5分钟构建6核i7的项目仅减少了大约15秒 . 考虑到需要重新复制到永久存储和丢失工作的可能性,15秒不足以激励使用RAM磁盘,并且可能没有太多动力在高RPM或SSD驱动器上花费数百美元 .

    小增益可能表明构建受CPU限制或Windows文件缓存相当有效,但由于两个测试都是从未缓存文件的状态完成的,因此我严重依赖于CPU绑定编译 .

    根据您编制的实际代码,您的里程可能会有所不同 - 所以请不要犹豫,进行测试 .

  • 0

    完成构建后,构建目录有多大?如果您坚持使用默认设置,那么您构建的每个程序集都将复制其所有的DLL依赖项及其依赖项的依赖项等到其bin目录 . 在我以前的工作中使用~40个项目的解决方案时,我的同事发现,到目前为止,构建过程中最昂贵的部分是反复复制这些程序集,并且一个构建可以生成相同DLL的千兆字节副本 . 再次 .

    以下是NDepend的作者Patrick Smacchia的一些有用的建议,他认为应该和不应该是单独的程序集:

    http://codebetter.com/patricksmacchia/2008/12/08/advices-on-partitioning-code-through-net-assemblies/

    基本上有两种方法可以解决这个问题,两者都有缺点 . 一个是减少组件数量,这显然是很多工作 . 另一个是重构您的构建目录,以便合并所有bin文件夹,并且项目不会复制其依赖项的DLL - 它们不需要,因为它们都已在同一目录中 . 这大大减少了在构建期间创建和复制的文件数量,但是设置起来可能很困难,并且可能会使您难以仅提取特定可执行文件所需的DLL以进行打包 .

  • 12

    也许采用一些常用函数并创建一些库,这样就不会为多个项目反复编译相同的源代码 .

    如果您担心混合的不同版本的DLL,请使用静态库 .

  • 6

    关闭VSS集成 . 您可能没有选择使用它,但DLL会被“意外”重命名...

    绝对检查您的预编译标头设置 . 布鲁斯道森的指南有点旧,但仍然非常好 - 检查出来:http://www.cygnus-software.com/papers/precompiledheaders.html

  • 2

    我有一个项目,有120或更多的exes,libs和dll,需要相当长的时间来构建 . 我使用一个批处理文件树,从一个主批处理文件调用make文件 . 我在过去使用增量(或者是气质) Headers 时遇到了奇怪的问题,所以我现在就避开它们 . 我不经常做一个完整的构建,并且通常在我散步一小时的时候离开它(所以我只能猜测它需要大约半小时) . 所以我理解为什么这对于工作和测试是行不通的 .

    对于工作和测试,我为每个应用程序(或模块或库)提供了另一组批处理文件,这些文件也具有所有调试设置 - 但这些仍然调用相同的make文件 . 我可能会不时地关闭DEBUG并决定构建或制作或者我是否还要构建模块可能依赖的库,依此类推 .

    批处理文件还将完成的结果复制到(或多个)测试文件夹中 . 根据设置,这在几秒到一分钟内完成(而不是半小时) .

    我使用不同的IDE(Zeus),因为我喜欢控制像.rc文件这样的东西,实际上更喜欢从命令行编译,即使我使用的是MS编译器 .

    如果有兴趣的话,很高兴发布这个批处理文件的例子 .

  • 8

    禁用源目录上的文件系统索引(特别是obj目录,如果您希望源代码可搜索)

  • 1

    如果这是一个Web应用程序,将批量生成设置为true可能会有所帮助,具体取决于方案 .

    <compilation defaultLanguage="c#" debug="true" batch="true" >
    

    你可以在这里找到一个概述:http://weblogs.asp.net/bradleyb/archive/2005/12/06/432441.aspx

  • 2

    您还可能想要检查循环项目引用 . 这对我来说只是一个问题 .

    那是:

    项目A参考项目B.

    项目B参考项目C.

    项目C参考项目A.

  • 2

    Xoreax IB的一个更便宜的替代品是使用我称之为超级文件构建的东西 . 它基本上是一个.cpp文件

    #include "file1.cpp"
    #include "file2.cpp"
    ....
    #include "fileN.cpp"
    

    然后编译超级单元而不是单个模块 . 我们已经看到编译时间从10-15分钟到1-2分钟 . 您可能需要体验每个uber文件中有多少#includes有意义 . 取决于项目 . 等等 . 也许你包括10个文件,也许20个 .

    你支付一笔费用,所以要小心:

    • 您无法右键单击文件并说出"compile...",因为您必须从构建中排除单个cpp文件并仅包含uber cpp文件

    • 您必须小心静态全局变量冲突 .

    • 添加新模块时,必须使uber文件保持最新

    这是一种痛苦,但对于一个在新模块方面基本上是静态的项目,初始痛苦可能是值得的 . 在某些情况下,我看到这种方法击败了IB .

  • 1

    如果它是一个C项目,那么你应该使用预编译的头文件 . 这在编译方面产生了巨大的差异倍 . 不确定cl.exe到底在做什么(没有使用预编译的头文件),它似乎在最终到达正确的位置之前在所有错误的位置寻找 lots 的STL头文件 . 这会为正在编译的每个.cpp文件添加整秒 . 不确定这是否是一个cl.exe错误,或VS2008中的某种STL问题 .

  • 74

    查看您正在构建的计算机,是否进行了最佳配置?

    我们通过确保安装了正确的SATA过滤器驱动程序,将我们最大的C企业级产品的构建时间从 19 hours 下调到16分钟 .

    微妙 .

  • 1

    Visual Studio 2005中有未记录的/ MP切换,请参阅http://lahsiv.net/blog/?p=40,它将基于文件而不是基于项目进行并行编译 . 这可能会加快编译最后一个项目,或者,如果您编译一个项目 .

  • 0

    选择CPU时:L1缓存大小似乎对编译时间有很大影响 . 此外,通常最好有2个快速核心而不是4个慢速核心 . Visual Studio不会非常有效地使用额外的内核 . (我的基础是我对C编译器的经验,但对于C#编译器来说也是如此 . )

  • 14

    我现在也确信VS2008存在问题 . 我在带有3G Ram的双核英特尔笔记本电脑上运行它,关闭了防病毒软件 . 编译解决方案通常非常灵活,但如果我一直在调试,后续重新编译通常会慢下来爬行 . 从连续主磁盘灯中可以清楚地看到存在磁盘I / O瓶颈(您也可以听到它) . 如果我取消构建和关闭VS磁盘活动停止 . 重启VS,重新加载解决方案,然后重建,速度要快得多 . Unitl下次

    我的想法是,这是一个内存分页问题 - VS只是耗尽内存而O / S开始页面交换以尝试腾出空间,但VS要求的不仅仅是页面交换可以提供,所以它会慢下来爬行 . 我想不出任何其他解释 .

    VS绝对不是RAD工具,是吗?

  • 11

    确定VS2008存在问题 . 因为我唯一做的就是安装VS2008以升级我用VS2005创建的项目 . 我的解决方案中只有2个项目 . 它并不大 . 使用VS2005进行编译:30秒使用VS2008进行编译:5分钟

  • 58

    到目前为止提供了很好的建议(不是说下面没有其他好的建议,如果你有问题,我建议你阅读,这对我们有什么帮助)

    • 新的3GHz笔记本电脑 - 失去使用率的力量在对管理层表示怀疑时起到了作用

    • 在编译期间禁用防病毒
      编译期间来自VSS(实际上是网络)

    • 'Disconnecting'我可能会让我们完全删除VS-VSS集成并坚持使用VSS UI

    仍然没有通过编译扯皮,但每一点都有帮助 .

    我们还测试了在新解决方案中构建应用程序新领域的实践,根据需要导入最新的dll,当我们对它们满意时,将它们集成到更大的解决方案中 .

    我们也可以通过创建临时解决方案来对现有代码执行相同的操作,这些解决方案仅封装我们需要处理的区域,并在重新集成代码后将它们丢弃 . 我们需要权衡重新整合这些代码所需的时间与我们获得的时间,因为没有Rip Van Winkle喜欢在开发过程中快速重新编译的经验 .

    Orion在评论中确实提到仿制药也可能有一个游戏 . 从我的测试来看,似乎确实有最小的性能损失,但不足以确定 - 由于光盘活动,编译时间可能不一致 . 由于时间限制,我的测试没有包含与实时系统中出现的一样多的泛型或代码,因此可能会累积 . 我不会避免在它们应该被使用的地方使用泛型,只是为了编译时的性能

  • 0

    我发现有一些东西可用于扩展 C# /.NET 版本:

    • 将小项目合并到更大的项目中,因为构建解决方案的每个项目开销很大 . (如果需要,使用 nDepend 来控制跨层呼叫)

    • 将所有项目构建到某个输出目录中,然后在所有项目引用上将“copy local”设置为false - 由于IO减少,这可能会导致大量加速 .

    • 关闭病毒检查程序以查看它是否有很大差异;如果是这样找到faster virus checker,或从中排除"hot"文件夹病毒检查扫描

    • 使用perforce监视器和sys内部工具来查看编译所花费的时间 .

    • 考虑使用ram磁盘放置输出目录 .

    • 考虑使用SSD

    • 更多的内存有时会产生很大的影响 - (如果你通过移除一个小的ram来减慢速度,可以减少机器中的ram,你可以通过添加更多来加快速度)删除不需要的项目引用(你可能有首先删除不需要的“使用”

    • 考虑为最低域层使用依赖注入框架和接口,因此只有在接口更改时才需要重新编译所有内容 - 根据接口更改的频率,这可能不会获得太多好处 .

相关问题