私は最近、ThreadStatic とマークされたフィールドのパフォーマンスの低下に関するこの投稿を読みました。これらは、通常のフィールド アクセスよりも 60 倍遅いようです。.NET 4 の ThreadLocal< T > のパフォーマンスは向上しますか?
高パフォーマンスのスレッド固有のストレージを提供する代替手段はありますか?
私は最近、ThreadStatic とマークされたフィールドのパフォーマンスの低下に関するこの投稿を読みました。これらは、通常のフィールド アクセスよりも 60 倍遅いようです。.NET 4 の ThreadLocal< T > のパフォーマンスは向上しますか?
高パフォーマンスのスレッド固有のストレージを提供する代替手段はありますか?
それは2008年のことであることに注意してください。フィールドでは、 .NET4の方が.NET3.5よりもはるかに高速であると思いますThreadStatic
。はっきりとは覚えていませんが、必要に応じてテストを実行できます。
とはいえ、テストの説明にはあまり納得できません。非現実的だからです。本当にループ内のスレッドローカルフィールドを繰り返し読み取る必要がありますか?一度読んでから、少し後で別のコードで読む可能性が高いのではないでしょうか。
最終的に、本当の問題は、これらのアプローチのいずれかまたは両方が特定の要件に対して十分に機能するかどうかです。パフォーマンス上の理由ではなく、適切な初期化が可能になるためです。例については、ランダム性に関する私の記事を参照ThreadLocal<T>
してください。ThreadStatic
[ThreadStatic]
よりもはるかにパフォーマンスが高いと彼らは言いThread.AllocateDataSlot
ます。
(Reflector によると)の実装には、カバーの下でThreadLocal<T>
使用する 16 の専用タイプがあります。[ThreadStatic]
それらが使い果たされて解放されなくなったら、 にTheadLocal<T>
切り替えますThread.AllocateDataSlot
。(実際には、 ごと<T>
に 16^3 スロットのようです。スロットを保持するジェネリック型を作成する非常に面白いスキームを実行します)
だから私[ThreadStatic]
は最速だと思います。
漏れやすい抽象化を常にチェックし、実装を確認することを忘れないでください! そのような最適化を時期尚早にスキップしないでください;-)