使用されたとき、自動メモリ管理は一般的に手動割り当てと同等かそれ以上の全体パフォーマンスが得られます。プログラマにとって重要なこととして、コレクターを必要以上にトリガーし、実行中にポーズするという誤りを避けることがあります。繰り返しの文字列連結は昔からある事例です。line;}ここで鍵となるポイントは、新しい部分が文字列の正しいところにひとつひとつ追加されないということです。もとの部分に新しい部分を加えたまったく新しい文字列が格納されます。値が増加されるため、消費されるヒープの量もまた増加し、この関数がコールされるたびに数百バイトの空きヒープ領域を容易に占有します。クラスを使用したよりよい例があります。その頻繁となりうる要因は暗黙的にはフレーム更新です。コールされるたびに新しい文字列が割り当てされ、新しいガベージが常に生成されます。そのほとんどはスコアが変更されたときのみテキストを更新することで節約できます。}}もうひとつの潜在的な問題は関数が配列の値を戻すときに発生します。result;}この種の関数は、値で埋められた新しい配列を作成するときに、非常にエレガントで便利です。繰り返しコールされると、真新しいメモリが毎回割り当てられます。配列は非常に大きくなりえるため、空きヒープ領域があっという間に使い切られることがあり、結果的に頻繁にガベージコレクションが行われます。この問題を回避する方法は配列が参照型であることを活用することです。関数に引数として渡される配列はその関数の中で更新することができて、結果は関数が戻った後も残ります。前述のような関数は、多くの場合に次のような関数で置き換えできます。}}これにより単に既存の配列の中身を新しい値で置き換えます。これにより初期割り当てがコールする元のコードの中で行われることが必要となるにも関わらず(ややエレガントでなくみえますが)、関数はコールされるときに新しいガベージを生成することはなくなります。前述のとおり、できるかぎり割り当てをさけることがベストです。完全には排除できないことを考えると、ゲームプレイへの進入を防ぐには主に二つのアプローチがあります。小さなヒープで速く頻繁なガベージコレクションこのアプローチがベストであるのは、長期間のゲームプレイにおいて、スムーズなフレームレートを実現することが主な関心事であるゲームの場合などです。このようなゲームは一般的に小さなブロックを頻繁に割り当てしますが、これらのブロックは短期間しか使用されません。