我们的编译时间变得非常慢,在双核2 2GHz、2G Ram机器上可能需要几分钟的20+时间。
这在很大程度上是由于我们的解决方案的规模已经增长到70+项目,以及VSS,当你有很多文件时,这本身就是一个瓶颈。(不幸的是,换掉VSS不是一个选项,所以我不希望这件事演变成VSS bash)
我们正在考虑合并项目。我们还在考虑使用多个解决方案来实现更大的关注点分离,并加快应用程序每个元素的编译时间。我可以预见,这将成为一个DLL地狱,因为我们试图保持同步。
我很想知道其他团队是如何处理这个伸缩问题的,当你的代码库达到临界值时,你会怎么做,以至于你浪费了半天的时间看着状态栏传递编译消息。
更新我忘了提一下这是一个C#解决方案。感谢所有C++的建议,但我已经有几年没有担心头文件了。
编辑:
到目前为止有帮助的好建议(并不是说下面没有其他好的建议,只是有帮助)
仍然不是通过编译来破解,但每一点都是有帮助的。
Orion确实在一条评论中提到,泛型也可能有作用。从我的测试中,似乎有一个最小的性能影响,但不是足够高,以确保-编译时间可能是不一致的磁盘活动。由于时间的限制,我的测试没有包括像在实时系统中出现的那么多的泛型或代码,所以可能会累积。我不会避免在应该使用泛型的地方使用它们,只是为了提高编译时的性能
解决方法
我们正在测试在新的解决方案中构建新的应用程序区域的实践,根据需要导入最新的dlls,当我们对它们满意时,将它们集成到更大的解决方案中。
我们也可以通过创建临时解决方案来封装我们需要处理的区域,并在重新集成代码后将其丢弃,从而对现有代码执行相同的操作。我们需要权衡一下重新集成这段代码所需的时间,以及我们在开发过程中没有Rip Van Winkle那样的快速重新编译经验所获得的时间。
https://stackoverflow.com/questions/55517
复制相似问题