大型代码库的C＃编译器在具有巨大RAM的机器上运行得更快吗？

Question

我已经看到在没有适当的程序集分解的情况下，在2G RAM计算机上运行的大型遗留代码库中存在一些非常慢的构建时间。所以，如果我想在不进行代码检修的情况下加快速度，那么16G（或其他如此庞大的数量）RAM机器是否会更快，如果神仙IT部门提供一个？换句话说，RAM是足够大的dotnet项目的主要瓶颈还是存在其他主要问题？

关于构建Java的类似情况的任何输入也是出于好奇心而受到赞赏。

Answer 1

一旦RAM比应用程序使用的RAM多，RAM的性能就不会提高。使用128GB内存可能不会有任何进一步的改进。

我们无法猜测所需的金额。通过查看任务管理器来衡量。

Answer 2

这肯定不会对你造成伤害......

对于开发机器来说2G非常小，我当然使用16G。

但是，构建时间迟早会被文件访问限制，所以虽然你可能会得到一些改进，但我怀疑你不会被它所震撼。 （[EDIT]作为评论者说，编译也可能受CPU限制。）

您是否考虑过并行构建（例如，请参阅此问题：Visual Studio 2010, how to build projects in parallel on multicore）。

或者，您是否可以重构代码库并将一些不太频繁更新的程序集移除到单独的sln中，然后将它们作为DLL引用（这在所有情况下都不是一个好主意，但有时它可能是有利的） 。从你的问题描述我猜这说起来容易做起来难，但这就是我们在代码库中取得好成绩的方式。

Answer 3

整个RAM问题实际上是投资回报率（ROI）之一。您添加到系统的RAM越多，应用程序搜索足够大的内存位置以存储特定大小的对象的可能性就越小，它就越快;然而，在某个点之后，系统将不太可能选择一个不足以存储对象的位置，以至于它没有任何意义。 （请注意，RAM棒的读/写速度也起到了作用）。

总结：@ 2gb RAM，你肯定应该把它升级到更像8gb或建议的16gb，但是做更多的事情几乎是没有意义的，因为瓶颈将来自处理器然后。      ALSO 注意RAM的速度也许是一个好主意，因为那时你的RAM会出现瓶颈，因为它最多只能处理XXXXmhz的时钟速度。一般来说，1600mhz是好的。