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

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

プロジェクトのマージを検討しています。また、アプリケーションの各要素について、懸念事項の分離とコンパイル時間の短縮を実現する複数のソリューションを検討しています。同期を維持しようとすると、これはDLLの地獄になるでしょう。

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

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

編集：

これまでに役に立った素晴らしい提案（以下に他の良い提案がないと言っているのではなく、何が役に立ったかだけです）

• 新しい3 GHzラップトップ-失われた使用率のパワーは、管理に不快感を与えるときに不思議に機能します
• コンパイル中にアンチウイルスを無効にする
• コンパイル中にVSS（実際にはネットワーク）から「切断」-VS-VSS統合を完全に削除して、VSS UIの使用に固執する

それでもコンパイルをすり抜けるわけではありませんが、すべてが役立ちます。

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

回避策

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

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

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

スピードアップの降順：

• Microsoftホットフィックス935225をインストールします。
• Microsoftホットフィックス947315をインストールします。
• 真のマルチコアプロセッサを使用します（つまり、Pentium 4 HTではなくIntel Core Duo 2）。
• 3つの並列ビルドを使用します。Visual Studio 2005では、[ ツール]> [オプション...]> [プロジェクトとソリューション]> [ビルドと実行]> [並列プロジェクトビルドの最大数 ]にオプションがあります。
• .ilk、.pdb、.cc、.hファイルのウイルス対策ソフトウェアを無効にし、変更時にのみウイルスをチェックします。ソースが存在するディレクトリのスキャンを無効にします。ばかげたことはしないでください。
• Chromiumコードを2番目のハードドライブに保存してビルドします。ビルドは実際にはスピードアップしませんが、少なくともgclientの同期またはビルドを実行すると、コンピューターは応答性を維持します。
• 定期的にハードドライブを最適化します。
• 仮想メモリを無効にします。

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

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

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

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

2015年5月の更新

私が行った取引（以下のコメントで）は、十分な関心が集まったら、プラグインをオープンソースにリリースすることでした。4年後の投票数は44票（Visual Studioには2つの後続バージョンがあります）であるため、現在優先度の低いプロジェクトです。

21のプロジェクトと20万のLOCを持つソリューションで同様の問題がありました。最大の違いは、ハードドライブの高速化でした。パフォーマンスモニターから、「平均 Disk Queue 'はラップトップで大幅に上昇し、ハードドライブがボトルネックであることを示します。

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

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

再構築時間= 112秒。

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

再構築時間= 72秒。

3）デスクトップコア2 Duo 3Ghz、シングル10000 RPM WDラプター

再構築時間= 39秒。

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

どの会社が開発者の給与に費やしているのかを考えると、受付係が使用しているのと同じPCを彼らに装備させることで、どれだけ無駄に購入することができるのかは狂気です。

C＃.NETビルドの場合、.NET Demonを使用できます。これは、Visual Studioのビルドプロセスを引き継いで高速化した製品です。

これは、行った変更を分析してこれを行い、実際に変更したプロジェクトだけでなく、実際に行った変更に依存した他のプロジェクトもビルドします。つまり、内部コードのみを変更する場合、ビルドする必要があるプロジェクトは1つだけです。

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

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

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

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

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

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

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

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

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

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

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

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

私たちは別の解決策についても考えています。

また、新しいプロジェクトで新しい（2番目の）ソリューションをセットアップしようとしましたか？この2番目のソリューションは、ソリューションフォルダーを使用してすべてのファイルを組み込むだけです。なぜなら、プロジェクトが1つだけの新しいソリューションのビルド時間を見ると、驚くかもしれません。

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

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

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

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

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

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

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

私はこの質問が古くなっていることに気づきましたが、このトピックは今日でもまだ興味があります。最近同じ問題が発生し、ビルドパフォーマンスを最も改善した2つの点は、（1）コンパイルに専用の（そして高速な）ディスクを使用し、（2）すべてのプロジェクトに同じ出力フォルダーを使用し、プロジェクトでCopyLocalをFalseに設定したことです。参照。

追加のリソース：

• /programming/8440/visual-studio-optimizations
• http://weblogs.asp.net/scottgu/archive/2007/11/01/tip-trick-hard-drive-speed-and-visual-studio-performance.aspx
• http://arnosoftwaredev.blogspot.com/2010/05/how-to-improve-visual-studio-compile.html
• http://blog.brianhartsock.com/2009/12/22/analyzing-visual-studio-build-performance/

一部の分析ツール：

tools-> options-> VC ++プロジェクト設定-> Build Timing = Yesは、すべてのvcprojのビルド時間を教えてくれます。

/Btコンパイラーのコマンドラインにスイッチを追加して、すべてのCPPファイルに要した時間を確認します

使用/showIncludesネストされたキャッチするには、（他のヘッダファイルをインクルードヘッダファイル）が含まれ、ファイルが前方宣言を使用してIOの多くを救うことができるかを参照してください。

これは、依存関係とパフォーマンスの負担を排除することにより、コンパイラのパフォーマンスを最適化するのに役立ちます。

より高速なハードドライブに投資するためにお金を使う前に、RAMディスク上に完全にプロジェクトを構築してみてください（RAMに余裕があると仮定して）。あなたはネット上で様々な無料のRAMディスクドライバを見つけることができます。SSDを含め、RAMディスクよりも高速な物理ドライブは見つかりません。

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

わずかな増加は、ビルドがCPUにバインドされていたか、Windowsファイルキャッシュがかなり効果的だったことを示している可能性がありますが、どちらのテストもファイルがキャッシュされていない状態から行われたため、CPUバインドコンパイルに大きく依存しています。

マイレージをコンパイルしている実際のコードによって異なる場合があります。テストをためらわないでください。

完全なビルドを行った後のビルドディレクトリのサイズはどれくらいですか？デフォルトの設定をそのまま使用する場合、ビルドするすべてのアセンブリは、その依存関係およびその依存関係の依存関係などのすべての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のみを引き出すことが難しい場合があります。

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

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

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

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

120以上のexe、libs、dllがあり、ビルドにかなりの時間がかかるプロジェクトがあります。1つのマスターバッチファイルからメイクファイルを呼び出すバッチファイルのツリーを使用しています。私は過去にインクリメンタル（または気質的）ヘッダーの奇妙なことに問題があったので、今は回避します。フルビルドはめったに行いません。通常、1時間の散歩に出かける間は1日の終わりにそれを残します（そのため、約30分しかかかりません）。ですから、それが作業やテストに役立たない理由を理解しています。

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

バッチファイルは、完了した結果を（またはいくつかの）テストフォルダーにもコピーします。設定に応じて、これは数秒から1分で完了します（たとえば、30分ではありません）。

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

興味があれば、このバッチファイルの例を投稿してください。

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

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

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

ここで概要を見つけることができます：http : //weblogs.asp.net/bradleyb/archive/2005/12/06/432441.aspx

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

あれは：

プロジェクトAはプロジェクトBを参照

プロジェクトBはプロジェクトCを参照

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

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

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

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

あなたは費用を支払うので注意してください：

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

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

C ++プロジェクトの場合は、プリコンパイル済みヘッダーを使用する必要があります。これにより、コンパイル時間が大幅に異なります。（プリコンパイル済みヘッダーを使用せずに）cl.exeが実際に何をしているのかわからない場合、最終的に正しい場所に移動する前に、すべての間違った場所で多くのSTLヘッダーを探しているようです。これにより、コンパイルされるすべての.cppファイルに秒単位が追加されます。これがcl.exeのバグなのか、VS2008のある種のSTLの問題なのかはわかりません。

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

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

微妙。

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

CPUを選択する場合：L1キャッシュサイズはコンパイル時間に大きな影響を与えるようです。また、通常、4つの遅いコアよりも2つの速いコアを使用することをお勧めします。Visual Studioは余分なコアをあまり効果的に使用しません。（これはC ++コンパイラーでの経験に基づいていますが、C＃コンパイラーにも当てはまる可能性があります。）

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

これはメモリページングの問題だと思います-VSはメモリを使い果たし、O / Sはスペースを作ろうとするページスワッピングを開始しますが、VSはページスワッピングが提供できる以上のものを要求しているので、クロールに時間がかかります。他の説明は思いつきません。

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

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

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

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

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

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

これまでに役立つ素敵な提案（以下に他の素敵な提案がないとは言わないでください。問題が発生している場合は、そのときに読んだことをお勧めします）

• 新しい3 GHzラップトップ-失われた使用率のパワーは、管理に不快感を与えるときに不思議に機能します
• コンパイル中にアンチウイルスを無効にする
• コンパイル中にVSS（実際にはネットワーク）から「切断」-VS-VSS統合を完全に削除して、VSS UIの使用に固執する

それでもコンパイルをすり抜けるわけではありませんが、すべてが役立ちます。

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

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

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