Reflection.Emit を介してアセンブリを生成する場合、.NET フレームワークは、Reflection.Emit クラスが GC されないようにする静的メンバーに参照を保持することを発見しました。
制限により DynamicMethod を使用できません。また、プログラムの過程で多くのアセンブリ (IronScheme のインクリメンタル コンパイラ) を生成します (1000 以上になる場合もあります)。
したがって、別のドメインでコード生成を処理し、後でアンロードすることを考えていました (これを処理する方法を決定していません)。
これがどれだけ高価になるか経験のある人はいますか？
私はあなたの特定のケースのためにそれをベンチマークします。
コストがかかることが判明した場合は、それらのいくつかを事前に作成し、必要に応じて使用し、バックグラウンドで新しいものを再作成して、未使用のものが常に十分に待機していることを確認します (スレッドプールに少し似ていますが、それらを再作成します)メモリを解放するたびに)。
私が理解しているように、スレッドを生成するよりも少し遅いだけです。
これについての実際の参照を見つけようとして、いくつかの調査を行っています。これまでのところ、これは私が思いつくことができる最高のものです:
http://msdn.microsoft.com/en-us/library/aa159887.aspx
方法の約 2/3 は、AppDomains の作成を「高価」と呼んでいますが、特定のコンテキストでのスレッドについても同じことが言えます。実際には、特定のスレッドが作成時に何をするかに依存します。
繰り返しますが、AppDomain は本質的にプロセス内のスレッド (または複数のスレッド) であり、必要に応じて論理区切り文字であることを理解しています。そのため、ランタイムは、個別の AppDomains がそれぞれに干渉するのを防ぐ特定の追加の保護が有効であることを保証します。他の。既存のプロセス (アプリケーション) 内で新しい AppDomain を作成するには、フレームワークが新しいスレッドの作成に関連するすべての作業を実行する必要があります。また、アプリケーションの残りの部分でそれをセットアップするための追加のオーバーヘッドも必要です (1 つ以上のロードが必要になる場合もあります)。アセンブリをメモリに)。最終的に、AppDomain はスレッドとプロセスの間のどこかに存在します。