このmsdnページでは、
ヒープに割り当てられるオブジェクトが少ないほど、ガベージコレクターが実行する必要のある作業が少なくなります。オブジェクトを割り当てるときは、必要な値が15バイトしかない場合に32バイトの配列を割り当てるなど、必要以上に切り上げた値を使用しないでください。
なぜこの推奨事項がここにあるのか誰かが知っていますか（明白なことは別として-私は彼らがこれをここに持っている理由は疑わしいです）？
単語の境界に丸められたスペースを割り当てることの害は何ですか？
パフォーマンスに影響はありますか？
割り当ての切り上げは、高度なヒープマネージャーが利用可能になる前の、管理されていないコードの昔の戦略でした。これにより、ヒープの断片化による悪影響が軽減され、ヒープ内に小さな空のブロックが多数あり、大きなブロックに組み合わせることができなくなりました。したがって、プログラムをOOMで終了させ、未使用のメモリを大量に使用します。今日残っている意味はありません。Windowsの低フラグメンテーションヒープは、割り当ても切り上げますが、問題を解決しました。小さな割り当ての場合は最大8の倍数。XP以降で使用可能で、Vista以降ではデフォルトでオンになっています。
コンパクトにして穴を取り除くことができるガベージコレクターがある場合、それは意味がありません。利益なしに、未使用のメモリを移動して、より多くの作業を行うだけです。
ヒープの断片化は、マネージコードで完全に解決された問題ではありません。ラージオブジェクトヒープには、再利用が難しい空の穴ができてしまう可能性があります。LOHは圧縮されず、移動するにはデータが多すぎます。また、80キロバイトを超えるオブジェクトの割り当てを切り上げることは、実際には意味があります。これを行うのは、メモリプロファイラーがLOHの問題があることを示した場合のみです。その時点で、最初に64ビットオペレーティングシステムへの移行を検討する必要があります。
単語の境界に丸められたスペースを割り当てることの害は何ですか？
害は、必要以上に多くのオブジェクトを作成できることです。これにより、GCの圧力が高くなります。これはまさにガイダンスが述べていることです。それが単語の境界であることに具体的なことは何もありません-それは必要以上に多くのメモリを割り当てることの問題です。
パフォーマンスに影響はありますか？
はい、GCがよりハードに動作する必要があるため、パフォーマンスに悪影響を与える可能性があります。