大きなバッファ（> 100MB）を扱うコードを扱っており、これらの操作はunsafeブロックで行われます。私はunsafeコードを避けるためにこれらをリファクタリングしたいと思います。私はそれに着手する前に、可能性のあるメモリパフォーマンスの向上（正/負/中立）について疑問に思っています。C＃の型の安全性はどのようにガベージコレクションに影響しますか？
私は、コンパイラが型を検証できれば、より良いコードを生成する可能性があると主張しています。これは良いGCパフォーマンスを意味します。これは有効なアサーションですか？あなたの経験は何ですか？ありがとう。
これは、バッファの用途（使用するバッファ）によって異なります。
このような大きなバッファはLOH（Large Object Heap）に配置されるため、その結果を必ず確認してください。
最高でも、私は同等のパフォーマンスが期待されます。
unsafeブロックは言語機能であり、CLR機能ではありません。したがって、実行時には実際には存在しません。 は実行時にが存在しますが、これを避けることができればかもしれませんはパフォーマンスの向上を得ますが、コスト/利益のトレードオフによって異なります。コードが100 MBのバッファをメモリに固定しない限り、パフォーマンスへの影響は心配しないでください。
私は期待する否定に影響します。通常の配列のインデックスと（あなたがそれらを を使用している私が思う？） の配列へのポインタへのアクセスを交換
：「安全」フラグの消失に加えて、私は危険なコードを削除するのいずれかの利点を見ることができません配列 の長さチェック- > less performanceを導入します。また、ほとんどの状況では、ポインタの算術演算は、たとえ母国語で知られているほど速くない場合でも、データ（配列）にアクセスする最も速い方法になります。
コンパイラは、とにかく安全でないブロックであっても、タイプ を「認識」します。私は にはそれのための機会を見ていない '良い'コードを作る。また、 の「より良い」コードでさえ、 が生成されるオブジェクトの数が少なくなる場合は、 GPパフォーマンスに影響します。 I が疑わしい場合、コンパイラは の新しいオブジェクトの作成を避けることができます。 - > no 改善です。
ピン止めについての議論は既に に記載されています。 を固定したオブジェクトを取り除くと、パフォーマンスが少し向上するかもしれませんが、小さなオブジェクトの場合は になります。 （ 圧縮ではありません）の大きなオブジェクトヒープではありません。 以降は移動されません。 - *型の安全性よりも関連するのは>ニュートラル
* 'unsafe'ブロックであなたのピン留めの活動です。 – Ani
はい、バッファはさまざまな操作の前に '固定'ブロックに固定されています。これはポインタで操作するために型安全性を取り除いた結果と信じています。 – Indy9000
ピン止めは何の違いもありません。これらの大きな配列はLOHに割り当てられ、移動不可能です。 –