私たちの現在のソリューション/プロジェクトには、いくつかのクラスが 1 つのファイルにまとめられています。これは、VS でのコンパイル時間が遅いために行われたと言われています。
これは確認済みの問題と解決策ですか?
VS2008 チーム システムを使用しているので、これらを分解できますか? 他の誰かがクラスを別のファイルに分割し、それでも優れたパフォーマンスを発揮しましたか?
私たちの現在のソリューション/プロジェクトには、いくつかのクラスが 1 つのファイルにまとめられています。これは、VS でのコンパイル時間が遅いために行われたと言われています。
これは確認済みの問題と解決策ですか?
VS2008 チーム システムを使用しているので、これらを分解できますか? 他の誰かがクラスを別のファイルに分割し、それでも優れたパフォーマンスを発揮しましたか?
私は VB.Net IDE チームで働いていますが、すべてを 1 つのファイルに入れると VS の実行が遅くなるだけで、速くはなりません。VB.Net は、さまざまなファイルのクラスで問題なく動作します。
これが違いを生むのは、信じられないほど遅いハードドライブと、物理ディスクの非常に異なる部分にあるファイルがある場合だけです (その結果、シーク命令がますます長くなります)。一般に、これは問題にはなりません。VB.Net IDE の場合、これは最初の起動時にのみ問題になります。この種の問題を解消するのに役立つキャッシングのレイヤーがいくつかあります。
コマンド ライン コンパイラが動作するのにかかる生の時間だけを考えれば、このアプローチの最小限の利点を発見できるかもしれません。IMHO、より重要な数値は、Visual Studio の応答性と Visual Studio の相対的なビルド時間です。非常に長いファイルがあると、VS の応答性が低下します (これは、クラスを単一のファイルに入れると最終的に発生することです)。
ハードウェアはどのようなものですか?
VS の大きなボトルネックは、大量の小さなファイルを読み書きする必要があることです。
高速なハード ドライブが 1 つまたは 2 つあると、パフォーマンス負荷が改善されます。
ソリューションの設計を検討するようにチームを説得したいと思うかもしれません。そこにすべてのプロジェクトを含む 1 つの巨大なソリューションを用意するのは最適ではないかもしれません。ビルド時間が実際に問題である場合は、可能であればソリューションを論理的な部分に分解することで解決したいと思います。
多くのクラスを 1 つのファイルにグループ化しても、通常のプロジェクトのビルド パフォーマンスが大幅に向上するとは思いません。それらをより多くのファイルに分割しても安全です (クラスごとに 1 つが標準です)。
私が遭遇した 1 つの例外は、「Web サイト」プロジェクトです。科学的なデータはありませんが、ファイルの数が増えると遅くなるようです。「Webアプリケーション」プロジェクトに変換できることを修正するには。
ソリューションにプロジェクトが多すぎると VS が遅くなることも知られていますが、それは問題のようには思えません。
これは確認済みの問題であり、確認済みの解決策です。今年の Tech Ed で、ベータ版をダウンロードして試すことができる VS2010 では問題がなくなると彼らは言いました。