そのため、大学の教授から、C# で文字列に連結を使用すると (つまり、プラス記号演算子を使用すると) メモリの断片化が発生するため、代わりに string.Format を使用する必要があると言われました。
いいえ、代わりにすべきことは、ユーザー調査を行い、ユーザーに焦点を当てた実際のパフォーマンス指標を設定し、それらの指標に対してプログラムのパフォーマンスを測定することです. パフォーマンスの問題が見つかった場合にのみ、適切なプロファイリング ツールを使用して、パフォーマンスの問題の原因を特定する必要があります。原因が「メモリの断片化」である場合は、「断片化」の原因を特定し、実験を試みて影響を軽減する手法を特定することで、それに対処します。
「文字列の連結を避ける」などの「ヒントとコツ」ではパフォーマンスは達成されません。パフォーマンスは、工学分野を現実的な問題に適用することによって達成されます。
より具体的な問題に対処するには:パフォーマンス上の理由から、フォーマットを優先して連結を避けるというアドバイスを聞いたことがありません。通常与えられるアドバイスは、buildersを優先して反復連結を避けることです。連結の反復は、時間と空間の二次関数であり、コレクション プレッシャーを生み出します。ビルダーは不要なメモリを割り当てますが、一般的なシナリオでは線形です。どちらもマネージ ヒープの断片化を作成しません。連結を繰り返すと、連続するガベージ ブロックが生成される傾向があります。
マネージ ヒープの不必要な断片化に至るパフォーマンスの問題が発生した回数は、まさに 1 回です。Roslyn の初期のバージョンでは、小さな長命オブジェクト、次に小さな短命オブジェクト、小さな長命オブジェクトの順に割り当てるパターンがありました... 数十万回続けて、結果として最大に断片化されたヒープコレクションでユーザーに影響を与えるパフォーマンスの問題を引き起こしました。これは、快適な椅子からコードをアドホックに分析するのではなく、関連するシナリオでのパフォーマンスを 注意深く測定することによって決定しました。
通常のアドバイスは、断片化を避けることではなく、プレッシャーを避けることです。Roslyn の設計中に、前述の割り当てパターンの問題が修正されると、フラグメンテーションよりもプレッシャーの方が GC パフォーマンスにはるかに大きな影響を与えることがわかりました。
あなたへの私のアドバイスは、教授に説明を求めるか、パフォーマンスメトリクスに対してより規律あるアプローチをしている教授を見つけることです.
とはいえ、連結の代わりにフォーマットを使用する必要がありますが、パフォーマンス上の理由からではありません。むしろ、コードの読みやすさ、ローカライズのしやすさ、および同様のスタイル上の懸念のためです。フォーマット文字列をリソースにしたり、ローカライズしたりできます。
最後に、ユーザーに提供する SQL クエリや HTML ブロックのようなものを作成するために文字列を組み合わせる場合は、これらの手法を使用しないでください。文字列構築のこれらのアプリケーションは、間違った使い方をすると、セキュリティに深刻な影響を与えます。文字列を独自に作成するのではなく、これらのオブジェクトの構築用に特別に設計されたライブラリとツールを使用してください。