我们的编译时间非常慢,在双核2GHz,2G Ram机器上可能需要20多分钟.
这很大程度上是由于我们的解决方案的规模已经发展到70多个项目,以及VSS,当你拥有大量文件时,它本身就是瓶颈.(不幸的是,交换VSS不是一个选项,所以我不希望它下降到VSS bash)
我们正在考虑合并项目.我们还在寻找多种解决方案,以便为应用程序的每个元素实现更大的关注点分离和更快的编译时间.我可以看到这将成为一个DLL地狱,因为我们试图保持同步.
我很想知道其他团队如何处理这个扩展问题,当你的代码库达到一个临界质量时你会怎么做,你正在看着状态栏传递编译消息的一半时间.
更新 我忽略了这是一个C#解决方案.感谢所有的C++建议,但是我已经有几年了,因为我不得不担心标题.
编辑:
到目前为止有很好的建议(不是说下面没有其他好的建议,只是帮助了什么)
仍然没有通过编译扯皮,但每一点都有帮助.
Orion在评论中确实提到仿制药也可能有一个游戏.从我的测试来看,似乎确实有最小的性能损失,但不足以确定 - 由于光盘活动,编译时间可能不一致.由于时间限制,我的测试没有包含与实时系统中出现的一样多的泛型或代码,因此可能会累积.我不会避免在它们应该被使用的地方使用泛型,只是为了编译时的性能
替代方法
我们正在测试在新解决方案中构建应用程序新领域的实践,根据需要导入最新的dll,当我们对它们感到满意时,将它们集成到更大的解决方案中.
我们也可以通过创建临时解决方案来对现有代码执行相同的操作,这些解决方案仅封装我们需要处理的区域,并在重新集成代码后将它们丢弃.我们需要权衡重新整合这些代码所需的时间与我们获得的时间,因为没有Rip Van Winkle喜欢在开发过程中快速重新编译的经验.
我有一个包含50个项目的解决方案,每个项目至少有100个文件(我认为这是相关的).
问题是当我构建解决方案或单个项目时,在"构建输出"窗口被写入之前有5到10秒的延迟.将"构建输出"详细程度设置为"诊断"并不表示延迟的原因是什么.没有文件被更改(先前构建)时甚至会发生此延迟.
=== Build: 0 succeeded, 0 failed, 10 up-to-date, 0 skipped ==========
当有变化时,在构建输出中,它表示构建需要大约2秒才能完成,但端到端大约需要7到12秒.
构建输出:
1>(omitted)
1>Time Elapsed 00:00:01.99
========== Build: 1 succeeded, 0 failed, 9 up-to-date, 0 skipped ==========
的MSBuild:
Build succeeded.
0 Warning(s)
0 Error(s)
Time Elapsed 00:00:02.17
C:\Projects\SharedKernel.Tests>
通过命令行运行MSBuild没有这样的延迟,2.17秒是按键盘完成的时间.
据我所知,msbuild任务本身在Visual Studio中快速执行,但似乎Visual Studio在msbuild任务启动之前在幕后做了一些导致这种延迟的事情.
当我检查的Visual Studio(devenv.exe的),虽然进程监视器,我注意到调用CreateFile,QueryDirectory以及CloseFile每个文件和文件夹的项目和项目的依赖.这似乎与查看时间表时的延迟相关.
如何减少从Visual Studio(右键单击项目>构建)开始构建构建过程到构建实际发生时的延迟？
我查看了以下答案以获得解决方案,但是它们要么不减少延迟,要么根本不适用: