c# - Visual Studio 2005 でのコンパイル時間が非常に遅い

Question

コンパイル時間が非常に遅くなり、デュアルコア 2GHz、2G RAM マシンでは 20 分以上かかることがあります。

これの多くは、70 以上のプロジェクトに成長したソリューションのサイズと、多数のファイルがある場合にそれ自体がボトルネックとなる VSS によるものです。（残念ながらVSSを交換することはオプションではないので、これがVSS bashに陥ることは望ましくありません）

統合プロジェクトを検討しています。また、アプリケーションの各要素の関心をより分離し、コンパイル時間を短縮するために、複数のソリューションを用意することも検討しています。物事を同期させようとすると、これは DLL 地獄になることがわかります。

他のチームがこのスケーリングの問題にどのように対処したかを知りたいです。コードベースがクリティカルマスに達し、ステータスバーがコンパイルメッセージを配信するのを見て半日を無駄にしているとき、あなたは何をしますか。

UPDATE これはC＃ソリューションであることに言及するのを怠りました。すべての C++ の提案に感謝しますが、ヘッダーについて心配する必要がなくなってから数年が経ちました。

編集：

これまでに役立った素敵な提案 (以下に他に素敵な提案がないと言っているのではなく、役立ったものだけです)

新しい 3 GHz ラップトップ - 管理者に文句を言うと、失われた使用率のパワーが驚異的に機能します
コンパイル中にアンチウイルスを無効にする
コンパイル中に VSS (実際にはネットワーク) から「切断」 - VS-VSS 統合を完全に削除し、VSS UI の使用に固執する可能性があります。

コンパイルをいじるわけではありませんが、すべてのビットが役立ちます。

Orion は、ジェネリックにも効果がある可能性があるとコメントで言及しました。私のテストでは、最小限のパフォーマンスヒットがあるように見えますが、十分に高いとは言えません。ディスクアクティビティが原因で、コンパイル時間が一定しない場合があります。時間の制限により、私のテストには、ライブシステムに表示されるほど多くのジェネリックまたはコードが含まれていなかったため、蓄積される可能性があります。コンパイル時のパフォーマンスのためだけに、使用されるはずの場所でジェネリックを使用することを避けません

回避策

新しいソリューションでアプリケーションの新しい領域を構築し、必要に応じて最新の dll をインポートし、満足のいくものになったら、それらをより大きなソリューションに統合する方法をテストしています。

また、作業が必要な領域をカプセル化するだけの一時的なソリューションを作成し、コードを再統合した後にそれらを破棄することにより、既存のコードと同じようにすることもできます。このコードを再統合するのにかかる時間と、開発中に Rip Van Winkle のような迅速な再コンパイルを経験しないことで得られる時間とを比較検討する必要があります。

score 74 · Accepted Answer

Chromium.org チームは、ビルドを高速化するためのいくつかのオプションをリストしました(この時点で、ページの半分ほど下にあります)。

高速化の降順:

Microsoft ホットフィックス935225をインストールします。

Microsoft ホットフィックス947315をインストールします。

真のマルチコアプロセッサ (つまり、Pentium 4 HT ではなく Intel Core Duo 2) を使用します。

3 つの並列ビルドを使用します。Visual Studio 2005 では、[ツール] > [オプション...] > [プロジェクトとソリューション] > [ビルドと実行] > [並列プロジェクトビルドの最大数] にオプションがあります。

.ilk、.pdb、.cc、.h ファイルのウイルス対策ソフトウェアを無効にし、変更時にのみウイルスをチェックします。ソースが存在するディレクトリのスキャンを無効にします。愚かなことをしないでください。

2 番目のハードドライブに Chromium コードを保存してビルドします。ビルドが実際に高速化されるわけではありませんが、少なくとも gclient sync またはビルドを実行するときにコンピューターの応答性が維持されます。

ハードドライブを定期的に最適化します。

仮想メモリを無効にします。

score 59 · Accepted Answer

1 つのソリューションに 100 近くのプロジェクトがあり、開発ビルド時間はわずか数秒です :)

Project referencesローカル開発ビルド用に、不要なプロジェクトを変更してアンロードする Visual Studio アドインを作成しましたDLL references(もちろん、それらを元に戻すオプションもありました)。

ソリューション全体を一度構築する
現在取り組んでいないプロジェクトをアンロードし、すべてのプロジェクト参照を DLL 参照に変更します。
チェックインする前に、すべての参照を DLL からプロジェクト参照に戻します。

一度に数個のプロジェクトしか作業していない場合でも、ビルドに数秒しかかかりません。デバッグ DLL にリンクしているため、追加のプロジェクトをデバッグすることもできます。通常、このツールは多数の変更を行うのに 10 ～ 30 秒かかりますが、それほど頻繁に行う必要はありません。

2015 年 5 月の更新

私が行った取引 (以下のコメントで) は、十分な関心が得られれば、プラグインをオープンソースにリリースするというものでした。4 年後には 44 票しか得られず (そして Visual Studio には現在 2 つの後続バージョンがある)、現在は優先順位の低いプロジェクトです。

score 24 · Accepted Answer

21 のプロジェクトと 1/2 百万の LOC を持つソリューションで同様の問題が発生しました。最大の違いは、より高速なハードドライブになったことです。パフォーマンスモニターからの「Avg. Disk Queue' はラップトップで大幅に跳ね上がり、ハードドライブがボトルネックであることを示していました。

総再構築時間のデータは次のとおりです...

1) ラップトップ、Core 2 Duo 2GHz、5400 RPM ドライブ (キャッシュは不明。標準の Dell inspiron でした)。

再構築時間 = 112 秒。

2) デスクトップ (標準の問題)、Core 2 Duo 2.3Ghz、シングル 7200RPM ドライブ 8MB キャッシュ。

再構築時間 = 72 秒。

3) デスクトップ Core 2 Duo 3Ghz、シングル 10000 RPM WD Raptor

再構築時間 = 39 秒。

10,000 RPM のドライブは控えめに言っても過言ではありません。大幅に高速化されたビルドに加えて、ドキュメントの表示、ファイルエクスプローラーの使用など、その他すべての処理が大幅に高速化されました。コード、ビルド、実行のサイクルが高速化され、生産性が大幅に向上しました。

企業が開発者の給与に費やしている金額を考えると、受付係が使用するのと同じ PC を購入するためにどれだけ無駄にできるかは正気ではありません。

score 14 · Accepted Answer

14

ウイルス対策をオフにします。コンパイル時間に年齢が追加されます。

于 2008-09-11T22:48:54.297 に答える

score 12 · Accepted Answer

分散コンパイルを使用します。Xoreax IncrediBuildは、コンパイル時間を数分に短縮できます。

通常、コンパイルに 5 ～ 6 時間かかる巨大な C\C++ ソリューションで使用しました。IncrediBuild は、この時間を 15 分に短縮するのに役立ちました。

score 11 · Accepted Answer

Visual Studio のコンパイル時間を数秒に短縮するための手順

残念ながら、Visual Studio は、アセンブリのインターフェイスの変更を重要でないコード本体の変更と区別するほどスマートではありません。この事実は、大規模な絡み合ったソリューションと組み合わせると、コードの 1 行を変更するたびに、不要な「フルビルド」の完全な嵐を引き起こすことがあります。

これを克服するための戦略は、自動参照ツリービルドを無効にすることです。これを行うには、「構成マネージャー」(ビルド/構成マネージャー...次に、アクティブなソリューション構成ドロップダウンで「新規」を選択) を使用して、デバッグ構成からコピーする「ManualCompile」と呼ばれる新しいビルド構成を作成しますが、 [新しいプロジェクト構成を作成する] チェックボックスをオンにしないでください。この新しいビルド構成では、すべてのプロジェクトのチェックを外して、どのプロジェクトも自動的にビルドされないようにします。[閉じる] をクリックして、この構成を保存します。この新しいビルド構成がソリューションファイルに追加されます。

IDE 画面の上部にあるビルド構成ドロップダウン (通常は「デバッグ」または「リリース」のいずれかが表示されます) を使用して、あるビルド構成から別のビルド構成に切り替えることができます。事実上、この新しい ManualCompile ビルド構成は、「ソリューションのビルド」または「ソリューションのリビルド」のビルドメニューオプションを役に立たなくします。したがって、ManualCompile モードの場合は、変更する各プロジェクトを手動でビルドする必要があります。これは、ソリューションエクスプローラーで影響を受ける各プロジェクトを右クリックし、[ビルド] または [再ビルド] を選択することで実行できます。全体のコンパイル時間がわずか数秒になったことがわかります。

この戦略が機能するためには、AssemblyInfo ファイルと GlobalAssemblyInfo ファイルにある VersionNumber が開発者のマシン上で静的なままである必要があり (もちろん、リリースビルド中はそうではありません)、DLL に署名しない必要があります。

この ManualCompile 戦略を使用する潜在的なリスクは、開発者が必要なプロジェクトをコンパイルするのを忘れる可能性があり、デバッガーを起動すると、予期しない結果 (デバッガーをアタッチできない、ファイルが見つからないなど) が発生することです。これを回避するには、'Debug' ビルド構成を使用して大規模なコーディング作業をコンパイルし、単体テスト中または範囲が限定された迅速な変更を行う場合にのみ ManualCompile ビルド構成を使用するのがおそらく最善です。

score 8 · Accepted Answer

これが C または C++ で、プリコンパイル済みヘッダーを使用していない場合は、使用する必要があります。

score 7 · Accepted Answer

メインソリューションには 80 以上のプロジェクトがあり、開発者が作業しているマシンの種類に応じて、ビルドに約 4 ～ 6 分かかりました。これは長すぎると考えました。すべてのテストで、実際に FTE を消費します。

では、ビルド時間を短縮するにはどうすればよいでしょうか。すでにご存知のように、ビルド時間を実際に損なうのはプロジェクトの数です。もちろん、すべてのプロジェクトを削除して、すべてのソースファイルを 1 つにまとめたくはありませんでした。しかし、それでも組み合わせることができるプロジェクトがいくつかありました。ソリューション内のすべての「リポジトリプロジェクト」には独自の単体テストプロジェクトがあったため、すべての単体テストプロジェクトを 1 つのグローバル単体テストプロジェクトにまとめただけです。これにより、約 12 個のプロジェクトでプロジェクトの数が削減され、ソリューション全体を構築するための時間が 40% 節約されました。

ただし、別の解決策を考えています。

また、新しいプロジェクトで新しい (2 つ目の) ソリューションをセットアップしようとしましたか? この 2 番目のソリューションでは、ソリューションフォルダーを使用してすべてのファイルを単純に組み込む必要があります。プロジェクトが 1 つしかない新しいソリューションのビルド時間を見て驚くかもしれません。

ただし、2 つの異なるソリューションを使用する場合は、慎重に検討する必要があります。開発者は、実際には 2 番目のソリューションで作業し、最初のソリューションを完全に無視する傾向があるかもしれません。70 以上のプロジェクトの最初のソリューションは、オブジェクト階層を処理するソリューションになるため、ビルドサーバーがすべての単体テストを実行するソリューションになるはずです。したがって、Continous Integration のサーバーは最初のプロジェクト/ソリューションである必要があります。オブジェクト階層を維持する必要がありますね。

プロジェクトを 1 つだけ使用する 2 つ目のソリューション (ビルドがはるかに高速になります) は、すべての開発者がテストとデバッグを行うプロジェクトよりも優れています。ただし、ビルドサーバーを見てそれらの世話をする必要があります! 何かが壊れている場合は、修正する必要があります。

score 7 · Accepted Answer

ライブラリ出力ディレクトリ内の DLL を直接参照するのではなく、参照がプロジェクト参照であることを確認してください。

また、絶対に必要な場合 (マスター EXE プロジェクト) を除いて、これらをローカルにコピーしないように設定してください。

score 6 · Accepted Answer

この応答を最初にここに投稿しました: https://stackoverflow.com/questions/8440/visual-studio-optimizations#8473 このページには、他にも多くの役立つヒントがあります。

Visual Studio 2008 を使用している場合は、/MP フラグを使用してコンパイルし、1 つのプロジェクトを並行してビルドできます。これは Visual Studio 2005 の文書化されていない機能でもあると読みましたが、自分で試したことはありません。

/M フラグを使用して複数のプロジェクトを並行してビルドできますが、これは通常、マシンで使用可能なコアの数に既に設定されていますが、これは VC++ にのみ適用されると思います。

score 6 · Accepted Answer

この質問は古くからあることに気づきましたが、このトピックは今日でも興味深いものです。最近同じ問題に悩まされましたが、ビルドのパフォーマンスを最も改善した 2 つのことは、(1) コンパイルに専用の (そして高速な) ディスクを使用すること、(2) すべてのプロジェクトに同じ出力フォルダーを使用すること、およびプロジェクトで CopyLocal を False に設定することでした。参照。

いくつかの追加リソース:

score 5 · Accepted Answer

いくつかの分析ツール:

tools->options->VC++ project settings -> Build Timing = Yes は、すべての vcproj のビルド時間を教えてくれます。

コンパイラコマンドラインにスイッチを追加/Btして、すべての CPP ファイルの使用量を確認します

/showIncludesネストされたインクルード (他のヘッダーファイルを含むヘッダーファイル) をキャッチし、前方宣言を使用して多くの IO を節約できるファイルを確認するために使用します。

これにより、依存関係とパフォーマンスの浪費を排除して、コンパイラのパフォーマンスを最適化できます。

score 5 · Accepted Answer

より高速なハードドライブに投資する前に、プロジェクト全体を RAM ディスク上に構築してみてください (RAM に余裕があると仮定します)。ネット上には、さまざまなフリー RAM ディスクドライバが見つかります。SSD を含め、RAM ディスクよりも高速な物理ドライブはありません。

私の場合、Incredibuild を使用して 7200 RPM SATA ドライブ上の 6 コア i7 でビルドするのに 5 分かかったプロジェクトは、RAM ディスクを使用することでわずか約 15 秒短縮されました。永続的なストレージに再コピーする必要性と、作業が失われる可能性を考慮すると、15 秒という時間は RAM ディスクを使用する十分なインセンティブではなく、おそらく高 RPM または SSD ドライブに数百ドルを費やすインセンティブもあまりありません。

小さなゲインは、ビルドが CPU バウンドであったか、Windows ファイルキャッシュがかなり効果的だったことを示している可能性がありますが、両方のテストはファイルがキャッシュされていない状態で行われたため、CPU バウンドのコンパイルに大きく傾いています。

コンパイルしている実際のコードによって、走行距離は異なる場合があります。テストすることを躊躇しないでください。

score 3 · Accepted Answer

完全なビルドを実行した後のビルドディレクトリの大きさは? デフォルトのセットアップをそのまま使用すると、ビルドするすべてのアセンブリが、その依存関係のすべての DLL とその依存関係の依存関係などをその bin ディレクトリにコピーします。以前の仕事で、約 40 のプロジェクトのソリューションを扱っていたとき、同僚は、ビルドプロセスの最もコストのかかる部分がこれらのアセンブリを何度もコピーすることであり、1 つのビルドで同じ DLL の数ギガバイトのコピーを何度も生成できることを発見しました。もう一度。

NDepend の作成者である Patrick Smacchia から、個別のアセンブリにする必要があるものとすべきでないものについての有益なアドバイスを次に示します。

http://codebetter.com/patricksmacchia/2008/12/08/advices-on-partitioning-code-through-net-assemblies/

これを回避するには基本的に 2 つの方法があり、どちらにも欠点があります。1 つはアセンブリの数を減らすことですが、これは明らかに大変な作業です。もう 1 つは、すべての bin フォルダーが統合され、プロジェクトが依存関係の DLL をコピーしないように、ビルドディレクトリを再構築することです。それらはすべて同じディレクトリにあるため、その必要はありません。これにより、ビルド中に作成およびコピーされるファイルの数が大幅に減少しますが、セットアップが難しく、パッケージ化のために特定の実行可能ファイルに必要な DLL だけを引き出すのが困難になる場合があります。

score 2 · Accepted Answer

ソースディレクトリ (特に、ソースを検索可能にする場合は obj ディレクトリ) でファイルシステムのインデックス作成を無効にします。

score 2 · Accepted Answer

おそらく、いくつかの一般的な関数を使用していくつかのライブラリを作成することで、同じソースが複数のプロジェクトで何度もコンパイルされないようにすることができます。

異なるバージョンの DLL が混同されることが心配な場合は、静的ライブラリを使用してください。

score 2 · Accepted Answer

120 以上の exe、lib、および dll があり、ビルドにかなりの時間がかかるプロジェクトがあります。1 つのマスターバッチファイルから make ファイルを呼び出すバッチファイルのツリーを使用します。過去にインクリメンタル (または気まぐれ) ヘッダーの奇妙な問題が発生したので、今はそれらを避けています。私はフルビルドを行うことはめったになく、通常は 1 時間ほど散歩に出かける間、1 日の終わりまでそのままにしておきます (したがって、約 30 分かかると推測できます)。ですから、それが作業とテストに使用できない理由を理解しています。

作業とテストのために、アプリ (またはモジュールまたはライブラリ) ごとに別のバッチファイルのセットを用意しています。これには、すべてのデバッグ設定も含まれていますが、これらは依然として同じ make ファイルを呼び出します。ときどき DEBUG のオンとオフを切り替えたり、ビルドや make を決定したり、モジュールが依存する可能性のあるライブラリもビルドするかどうかを決定したりします。

また、バッチファイルは、完了した結果を (または複数の) テストフォルダーにコピーします。設定にもよりますが、これは数秒から 1 分で完了します (30 分ではありません)。

.rc ファイルなどを制御したいので、別の IDE (Zeus) を使用しました。実際には、MS コンパイラを使用していますが、コマンドラインからコンパイルすることを好みます。

誰かが興味を持っている場合は、このバッチファイルの例を投稿してください。

score 2 · Accepted Answer

VSS 統合をオフにします。それを使用する選択肢はないかもしれませんが、DLL は常に「誤って」名前が変更されます...

そして、コンパイル済みのヘッダー設定を必ず確認してください。Bruce Dawson のガイドは少し古いですが、それでも非常に優れています。チェックしてみてください: http://www.cygnus-software.com/papers/precompiledheaders.html

score 1 · Accepted Answer

あなたの会社は、たまたま Entrust を PKI/暗号化ソリューションに使用していませんか? 結局のところ、C# で構築されたかなり大規模な Web サイトのビルドパフォーマンスは最悪で、Rebuild-All で 7 分以上かかっていました。

私のマシンは 16 GB の RAM と 512 GB の SSD を搭載した i7-3770 であるため、パフォーマンスはそれほど悪くなかったはずです。同じコードベースをビルドする古いセカンダリマシンでは、ビルド時間が非常に高速であることに気付きました。そこで、両方のマシンで ProcMon を起動し、ビルドのプロファイリングを行い、結果を比較しました。

驚いたことに、パフォーマンスの遅いマシンには 1 つの違いがありました。それは、スタックトレース内の Entrust.dll への参照です。この新しく取得した情報を使用して、引き続き StackOverflow を検索したところ、MSBUILD (VS2010) very slow on some machinesが見つかりました。受け入れられた回答によると、問題は Entrust ハンドラーがネイティブの Microsoft ハンドラーではなく .NET 証明書チェックを処理していたという事実にあります。また、Entrust v10 では、Entrust 9 で蔓延しているこの問題が解決されることも示唆されています。

私は現在それをアンインストールしており、ビルド時間は24 秒に急落しました。YYMV は、現在構築しているプロジェクトの数を示しており、問い合わせていたスケーリングの問題に直接対応していない可能性があります。ソフトウェアのアンインストールに頼らずに修正を提供できる場合は、この回答に編集を投稿します。

score 1 · Accepted Answer

C++ プロジェクトの場合は、プリコンパイル済みヘッダーを使用する必要があります。これにより、コンパイル時間に大きな違いが生じます。cl.exe が実際に何をしているのか (プリコンパイル済みヘッダーを使用していないため) は不明ですが、最終的に正しい場所に移動する前に、間違った場所すべてで多数の STL ヘッダーを探しているようです。これにより、コンパイル中のすべての .cpp ファイルに 1 秒が追加されます。これが cl.exe のバグなのか、VS2008 の何らかの STL の問題なのかは不明です。

score 1 · Accepted Answer

また、循環プロジェクト参照を確認することもできます。それはかつて私にとって問題でした。

あれは：

プロジェクト A がプロジェクト B を参照している

プロジェクト B はプロジェクト C を参照します。

プロジェクト C はプロジェクト A を参照します

score 1 · Accepted Answer

CPU を選択する場合: L1 キャッシュのサイズは、コンパイル時間に大きな影響を与えるようです。また、通常は、遅いコアを 4 つ使用するよりも、高速なコアを 2 つ使用する方が適切です。Visual Studio は余分なコアをあまり効果的に使用しません。(これは C++ コンパイラでの経験に基づいていますが、おそらく C# コンパイラにも当てはまります。)

score 1 · Accepted Answer

また、VS2008 に問題があることも確信しています。ウイルス対策をオフにして、3G RAMを搭載したデュアルコアIntelラップトップで実行しています。多くの場合、ソリューションのコンパイルは非常にスムーズですが、デバッグを行っていると、その後の再コンパイルが遅くなることがよくあります。ディスク I/O のボトルネックがあることは、メインディスクの継続的なライトから明らかです (これも聞こえます)。ビルドをキャンセルして VS をシャットダウンすると、ディスクアクティビティが停止します。VS を再起動し、ソリューションをリロードしてから再構築すると、はるかに高速になります。次回ユニット

私の考えでは、これはメモリページングの問題です。VS はメモリを使い果たし、O/S はページスワッピングを開始してスペースを作ろうとしますが、VS はページスワッピングが提供できる以上のものを要求するため、クロールが遅くなります。それ以外の説明が思いつきません。

VS は間違いなく RAD ツールではありませんね。

score 1 · Accepted Answer

Xoreax IB に代わる安価な方法の 1 つは、私が uber-file ビルドと呼んでいるものを使用することです。基本的には.cppファイルです

#include "file1.cpp"
#include "file2.cpp"
....
#include "fileN.cpp"

次に、個々のモジュールではなく、uber ユニットをコンパイルします。コンパイル時間が 10 ～ 15 分から 1 ～ 2 分に短縮されました。uber ファイルあたりの #include の数を実験する必要があるかもしれません。プロジェクトによって異なります。など。おそらく10個、おそらく20個のファイルを含めます。

あなたはコストを支払うので注意してください：

個々の cpp ファイルをビルドから除外し、uber cpp ファイルのみを含める必要があるため、ファイルを右クリックして「コンパイル...」と言うことはできません。
静的グローバル変数の競合に注意する必要があります。
新しいモジュールを追加するときは、uber ファイルを最新の状態に保つ必要があります

それは一種の苦痛ですが、新しいモジュールに関して大部分が静的であるプロジェクトの場合、最初の苦痛はそれだけの価値があるかもしれません. 場合によっては、この方法が IB に勝るのを見てきました。

score 1 · Accepted Answer

構築しているマシンを見て、最適に構成されていますか?

適切な SATA フィルタードライバーを確実にインストールすることで、最大の C++ エンタープライズ規模製品のビルド時間が19 時間から16 分に短縮されました。

微妙。

score 1 · Accepted Answer

Visual Studio 2005 には文書化されていない /MP スイッチがあります。http://lahsiv.net/blog/?p=40を参照してください。これにより、プロジェクトベースではなくファイルベースで並列コンパイルが可能になります。これにより、最後のプロジェクトのコンパイルが高速化される場合があります。または、1 つのプロジェクトをコンパイルする場合です。

score 1 · Accepted Answer

これが Web アプリの場合、シナリオによっては、バッチビルドを true に設定すると役立つ場合があります。

<compilation defaultLanguage="c#" debug="true" batch="true" >

ここで概要を確認できます: http://weblogs.asp.net/bradleyb/archive/2005/12/06/432441.aspx

score 0 · Accepted Answer

0

ここで修正を見つけました：http://blogs.msdn.com/b/vsdteam/archive/2006/09/15/756400.aspx

于 2011-08-30T15:27:49.180 に答える

score 0 · Accepted Answer

C# や .NET のビルドを高速化するのに役立つとわかったことがいくつかあります。

ソリューションの構築にはプロジェクトごとに大きなオーバーヘッドがあるため、小さなプロジェクトを大きなプロジェクトに結合します。(レイヤー間の呼び出しを制御する必要がある場合は、 nDependを使用します)
すべてのプロジェクトをいくつかの出力ディレクトリにビルドしてから、すべてのプロジェクト参照で「ローカルにコピー」を false に設定します。これにより、IO が減少するため、大幅な速度向上につながる可能性があります。
ウイルスチェッカーをオフにして、大きな違いがあるかどうかを確認します。その場合は、より高速なウイルスチェッカーを見つけるか、「ホット」フォルダーをウイルスチェッカーのスキャンから除外します。
perforce モニターと sys 内部ツールを使用して、コンパイルに時間がかかっていることを確認してください。
出力ディレクトリを置く RAM ディスクを検討してください。
SSDの使用を検討する
メモリを増やすと大きな効果が得られる場合があります – (小さな RAM を削除して速度が大幅に低下する場合は、マシンの RAM を減らします。RAM を追加すると速度が大幅に向上する可能性があります) 不要なプロジェクト参照を削除します (必要になる場合があります最初に不要な「使用」を削除します)
最下層のドメインレイヤーに依存性注入フレームワークとインターフェイスを使用することを検討してください。これにより、インターフェイスが変更された場合にのみすべての再コンパイルが必要になります。インターフェイスが変更される頻度によっては、あまり効果がない可能性があります。

score 0 · Accepted Answer

次のことがコンパイル速度に役立つことがわかりました。コンパイルを繰り返した後 (メモリ内での反復開発)、VS2008 を終了します。obj次に、プロジェクトディレクトリに移動し、すべてのフォルダーとフォルダーを削除しbin、プロジェクトを元に戻すと、コンパイル時間が大幅に短縮されました。これは、Clean solutionVS2008 内のアクションに似ています。

これが誰にとっても役立つかどうかを確認したいだけです。

score 0 · Accepted Answer

VS2008に問題があることは確かです。私が行った唯一のことは、VS2005 で作成されたプロジェクトをアップグレードするために VS2008 をインストールすることです。私のソリューションには 2 つのプロジェクトしかありません。大きくないです。VS2005 でのコンパイル: 30 秒 VS2008 でのコンパイル: 5 分

score 0 · Accepted Answer

これまでに役立った素敵な提案 (以下に他に素敵な提案がないというわけではありません。問題がある場合は、それを読むことをお勧めします。私たちを助けてくれたものだけです)

新しい 3 GHz ラップトップ - 管理者に文句を言うと、失われた使用率のパワーが驚異的に機能します
コンパイル中にアンチウイルスを無効にする
コンパイル中に VSS (実際にはネットワーク) から「切断」 - VS-VSS 統合を完全に削除し、VSS UI の使用に固執する可能性があります。

コンパイルをいじるわけではありませんが、すべてのビットが役立ちます。

また、新しいソリューションでアプリケーションの新しい領域を構築し、必要に応じて最新の dll をインポートし、満足できる場合はそれらをより大きなソリューションに統合する方法をテストしています。

また、作業が必要な領域をカプセル化するだけの一時的なソリューションを作成し、コードを再統合した後にそれらを破棄することにより、既存のコードと同じようにすることもできます。このコードを再統合するのにかかる時間と、Rip Van Winkle のような開発中の迅速な再コンパイルを経験しないことで得られる時間とを比較検討する必要があります。

Orion は、ジェネリックにも効果がある可能性があるとコメントで言及しました。私のテストでは、最小限のパフォーマンスヒットがあるように見えますが、確実に高くはありません。ディスクアクティビティが原因で、コンパイル時間に一貫性がない場合があります。時間の制約により、私のテストには、ライブシステムに表示されるほど多くのジェネリックまたはコードが含まれていなかったため、蓄積される可能性があります。コンパイル時のパフォーマンスのためだけに、使用されるはずの場所でジェネリックを使用することを避けません

score -1 · Accepted Answer

Visual Studio のパフォーマンスが遅い…解決しました! 2014 年 9 月 24 日ウズマ・アビディ

今日、奇妙なパフォーマンス関連の問題が発生しました。私の Microsoft Visual Studio は、最も単純な操作でさえ実行に時間がかかりすぎているように見えました。私はググって、アドインを無効にしたり、Visual Studio の最近のプロジェクトリストをクリアしたりするなど、人々が持っていたいくつかのアイデアを試しましたが、それらの提案は問題を解決していないようです。Windows SysInternals の Web サイトには、実行中のプログラムによるレジストリとファイルへのアクセスを盗聴する Process Monitor というツールがあったことを思い出しました。Visual Studio は何かを企んでいるように思えたので、Process Monitor はそれが何であるかを理解するのに役立つはずです。最新バージョンをダウンロードし、表示フィルターを少しいじって実行したところ、恐ろしいことに、C の 10,000 を超えるフォルダーにアクセスしていたため、Visual Studio が非常に遅いことがわかりました。ほとんどの IDE 操作で \Users\krintoul\AppData\Local\Microsoft\WebSiteCache 。なぜそんなに多くのフォルダーがあったのか、そして Visual Studio がそれらをどう処理しているのかはわかりませんでしたが、それらのフォルダーを圧縮して別の場所に移動した後、Visual Studio のパフォーマンスが大幅に改善されました。

Windows SysInternals Web サイトには、ネットワーク管理、セキュリティ、システム情報などに役立つユーティリティが他にも多数あります。見てみな。きっと価値のあるものが見つかります。

c# - Visual Studio 2005 でのコンパイル時間が非常に遅い

34 に答える 34

1 つのソリューションに 100 近くのプロジェクトがあり、開発ビルド時間はわずか数秒です :)

2015 年 5 月の更新

Related

Reference