簡単な質問...
他の言語では、パフォーマンス上の理由から、ライブラリのコードの一部がプラットフォーム固有のストレートCで記述されている場合があることを私は知っています。このような場合、可能な限りライブラリコードを使用することで、パフォーマンスを大幅に向上させることができます。
では、.NETプラットフォームはこれを行いますか？Microsoftの基本クラスライブラリの実装は、マネージコードで一致することを期待できない方法で最適化されていますか？
自分で作成する代わりに、KeyValuePairをタイプセーフなタプル構造体として使用するようなものはどうでしょうか。
私の知る限り、.NET Frameworkは、他の方法ではアクセスできないハードウェアアクセラレーションなどへのフックを作成するようにコンパイルされていないため、KeyValuePairやなどの単純なものについてTupleは、おそらく安全に自分で作成できます。
ただし、標準のフレームワーククラスを使用することには他にも多くの利点があり、強い理由なしに自分で作成することを躊躇します。
@gordyは、標準のフレームワーククラスがすべての人とその犬によって使用されていることも良い点です。そのため、次の事実だけでパフォーマンスがわずかに向上します。
私はこれを自分で疑問に思いましたが、Reflectorですべてのベースライブラリを「逆コンパイル」できるので、そうではないと思います。
コードがすでにジッティングされてキャッシュされている可能性が高いという点で、自家製のものよりもパフォーマンス上の利点がおそらくまだあります。
十分に速くないことを測定した場合を除いて、ほとんどの場合、組み込みのクラスを使用することをお勧めします。
MSは、高速で信頼性の高いものを構築するために多くの時間と労力を費やしたと確信しています。あなたがそれらを打ち負かすことができることは完全に可能です...数週間の努力の後。ほとんどの場合、それは時間の価値があるとは思いません。
何かを書き直しても大丈夫だと思われるのは、必要なことをすべて実行できないときだけです。時間のコストとそれに関連する難しさに注意してください。
パフォーマンスに合わせたいと思ったことはありますか？おそらく、彼らのコードは完全にテストされ、非常に最適化されていることを覚えておいてください。したがって、直接満たすBCLタイプがないという非常に特別なニーズがない限り、それは価値のある努力ではないと思います。
そして、.NET4.0にはすでに優れたTuple<>実装があります。ただし、以前のバージョンの.NETでは、KeyValuePairよりも大きいものが必要な場合は、独自にロールする必要がありました。
実際のパフォーマンスの向上は、MSチームがライブラリメソッドを構築してテストしたことによるものです。バグを発生させることなくオブジェクトが動作するという非常に高い快適さで安心できます。
次に、車輪の再発明の問題があります。あなたは本当にそうする大きな理由を持っている必要があります。
主なパフォーマンス上の理由は、常にアーキテクチャまたは複雑なアルゴリズムにあり、言語は関係ありません。
Miscrosoft基本クラスライブラリには、常に「重い」メソッドの複雑な説明が付属しています。したがって、それを使用することを簡単に決定したり、実装または使用する別の「より高速な」アルゴリズムを見つけることができます。
重いアルゴリズム（グラフィックス、アーカイブなど）に関しては、低レベルの言語に移行することでパフォーマンスが向上するので便利です。