C# の Nullable 型では、'as' 演算子は常に 'is' よりもパフォーマンス上の利点を提供しますか?

"as" 演算子と Null 許容型によるパフォーマンスの驚き

C# in Depth の第 4 章では、Null 許容型と "as" 演算子について説明しています。具体的には、型チェックに "as" を使用すると、プロセスが単一の型チェックと値チェックに簡素化されるため、従来の "is" チェックとキャストよりもパフォーマンスが向上することが期待されています。しかし、驚くべき結果が観察されました。

パフォーマンス ベンチマーク テスト

パフォーマンスを評価するために、多数の null 参照と文字列参照を含むオブジェクト配列内の整数を合計するベンチマーク テストが実施されました。 。テストでは、次のコード スニペットの実行時間を測定しました。

• 「is」を使用した C# 1 スタイルのコードと、キャストを使用した
• コード"as" 演算子
• LINQソリューション

研究者が驚いたことに、C# 1 コードは "as" コードと LINQ コードの両方を大幅に上回っていました。

結果の分析

パフォーマンスの不一致は次の原因によるものです。要素:

「is」とキャストの JIT コンパイラーの最適化:
「is」演算子のテストと後続のキャストは JIT コンパイラーによって最適化でき、その結果、マシンの効率が高くなります。最小限の命令数で実行されるコード。この最適化が可能なのは、ボックス化された値型を、値の変換やコピーを行わずに、同じ型の変数に直接ボックス化解除できるためです。

Nullable への変換の複雑さ
:

int にキャストしますか? "as" を使用すると、ボックス化された整数の値表現が Nullable のメモリ レイアウトと異なるため、より複雑な変換プロセスが必要になります。これには、JIT_Unbox_Nullable と呼ばれる汎用のボックス化解除ヘルパー関数の関与が必要になります。これにより、その汎用的な性質と型チェックにより追加のオーバーヘッドが発生します。
LINQ の予期しない動作:

The OfType LINQ の () 拡張メソッドも、「is」演算子と JIT_Unbox() ヘルパーを利用します。 関数。ただし、より安価であるはずであるという期待にもかかわらず、そのパフォーマンスは Nullable にキャストされた「as」と同等でした。この矛盾は、ngen.exe によって引き起こされる潜在的な問題に起因する可能性があります。

結論

「as」演算子は型チェックと null 許容値の処理を実行する便利な方法を提供しますが、そのパフォーマンス特性は次のとおりです。特定のシナリオでは、必ずしも期待どおりになるとは限りません。 C# 1 で「is」とキャスト用に生成された最適化されたコードは、多数のアンボックス操作が含まれる場合でも依然として大幅に高速であり、コーディング手法を選択する際にパフォーマンスへの影響を考慮することの重要性が強調されています。

以上がC# の Nullable 型では、'as' 演算子は常に 'is' よりもパフォーマンス上の利点を提供しますか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。