2G RAM マシンで実行されている、適切なアセンブリ分解を行わない大規模なレガシー コードベースで、ビルド時間が実際に遅いのを見てきました。では、コードをオーバーホールせずに速度を上げたい場合、妖精の IT 部門が提供した場合、16G (または他のそのような膨大な数) の RAM マシンは根本的に高速になるでしょうか? 言い換えれば、RAM は十分に大きな dotnet プロジェクトの主要なボトルネックですか、それとも他に支配的な問題がありますか?
純粋な好奇心から、Java を構築するための同様の状況についての意見も歓迎します。
アプリケーションが使用するよりも多くのRAMを使用すると、RAMを追加してもパフォーマンスは向上しません。128GBのRAMを使用しても、これ以上の改善は見られない可能性があります。
必要な量を推測することはできません。タスクマネージャーを見て測定します。
それは確かにあなたに害を及ぼすことはありません...
2Gは開発マシンとしてはかなり小さいので、当然16Gを使用します。
ただし、ビルド時間は遅かれ早かれファイルアクセスによって制限されるため、少し改善されるかもしれませんが、それに驚かされることはないと思います。（[編集]コメンターが言うように、コンパイルもCPUにバインドされる可能性があります）。
並列ビルドを調べましたか（たとえば、このSOの質問：Visual Studio 2010、マルチコアでプロジェクトを並列にビルドする方法を参照してください）。
または、コードベースを再構築し、更新頻度の低いアセンブリを別のslnに削除して、それらをDLLとして参照することはできますか（これはすべての場合に優れたアイデアではありませんが、便利な場合があります）。問題の説明から、これは口で言うほど簡単ではないと思いますが、これがコードベースで良好な結果を達成した方法です。