我们的编译时间非常慢,在双核2GHz,2G Ram机器上可能需要20多分钟.
这很大程度上是由于我们的解决方案的规模已经发展到70多个项目,以及VSS,当你拥有大量文件时,它本身就是瓶颈.(不幸的是,交换VSS不是一个选项,所以我不希望它下降到VSS bash)
我们正在考虑合并项目.我们还在寻找多种解决方案,以便为应用程序的每个元素实现更大的关注点分离和更快的编译时间.我可以看到这将成为一个DLL地狱,因为我们试图保持同步.
我很想知道其他团队如何处理这个扩展问题,当你的代码库达到一个临界质量时你会怎么做,你正在看着状态栏传递编译消息的一半时间.
更新 我忽略了这是一个C#解决方案.感谢所有的C++建议,但是我已经有几年了,因为我不得不担心标题.
编辑:
到目前为止有很好的建议(不是说下面没有其他好的建议,只是帮助了什么)
仍然没有通过编译扯皮,但每一点都有帮助.
Orion在评论中确实提到仿制药也可能有一个游戏.从我的测试来看,似乎确实有最小的性能损失,但不足以确定 - 由于光盘活动,编译时间可能不一致.由于时间限制,我的测试没有包含与实时系统中出现的一样多的泛型或代码,因此可能会累积.我不会避免在它们应该被使用的地方使用泛型,只是为了编译时的性能
替代方法
我们正在测试在新解决方案中构建应用程序新领域的实践,根据需要导入最新的dll,当我们对它们感到满意时,将它们集成到更大的解决方案中.
我们也可以通过创建临时解决方案来对现有代码执行相同的操作,这些解决方案仅封装我们需要处理的区域,并在重新集成代码后将它们丢弃.我们需要权衡重新整合这些代码所需的时间与我们获得的时间,因为没有Rip Van Winkle喜欢在开发过程中快速重新编译的经验.
多年前有人问为什么c#不允许像Java这样的增量编译.El Skeet说它与Java输出.class文件而不是程序集有关.
现在已经发布了像Mono编译器即服务这样的2011年和常规事物,为c#创建增量编译器需要做些什么？
编辑:大家都在谈论这不是一个问题,这里是Jon Skeet从我链接到的主题的引用:
你是建议你永远不会发现自己在等待构建？甚至15秒？如果一个构建需要15秒,你想在一小时内建立20次(我当然使用TDD),这意味着我浪费了5分钟.休息5分钟是一回事 - 这是一种放松等待的好方法 - 但是被耽搁15次20次可能会非常令人沮丧.做任何有用的东西都不够长(除了喝一杯),但它足够刺激.
我怀疑有两个因素会导致我感到烦恼的程度,其他人显然没有:1)TDD真的依赖于更快的转变2)在Eclipse中使用Java时,这种延迟非常罕见