サイズが常に変化するポイント データ (パーティクル用) の配列があります。変化するサイズに適応するために、次のようなコードを使用して、約 60 Hz で適切なサイズのバッファーを作成します。
free(points);
points = malloc(sizeof(point3D) * pointCount);
これは受け入れられますか、それとも別の方法がありますか? これにより、アプリの速度が低下したり、メモリのスラッシングが発生したりする可能性はありますか? シミュレーターのインストゥルメントの下で実行すると、特に悪くはありませんが、シミュレーターはデバイスとは異なることがわかります。
編集: 執筆時点では、開発者ライセンスがないとデバイスでテストできませんでした。ライセンスがなく、デバイスでプロファイリングできませんでした。
推定粒子数から始めて、mallocそのサイズの配列を -ing してみてください。次に、パーティクル数を増やす必要がある場合は、 を使用reallocして既存のバッファのサイズを変更します。そうすれば、実行している割り当て/解放操作の量を最小限に抑えることができます。
メモリを無駄にしないようにしたい場合は、最後の 100 個 (またはそれくらい) のパーティクル カウントの記録を保持することもできます。そのセットの最大パーティクル カウントが現在のバッファ サイズの 75% 未満 (たとえば) である場合は、バッファのサイズを小さくして、小さいパーティクル カウントに合わせます。
メモリの割り当ては、あるものに比べて速く、他のものに比べて遅いです。平均的な Objective-C プログラムは、1 秒あたり 60 をはるかに超える割り当てを行います。数百万バイトの割り当ての場合、malloc+free にかかる時間は 1,000 秒未満です。算術演算と比較すると、遅いです。でも、他のものに比べたら速いです。
あなたのケースで十分に速いかどうかは、テストの問題です。iPhone で 60 Hz のメモリ割り当てを行うことは確かに可能です。プロセッサは 600 MHz で動作します。
ただし、これは確かにメモリを再利用するための良い候補のようです。プールのサイズを追跡し、さらに必要な場合はさらに割り当てます。メモリを割り当てない方が、割り当てるよりも常に高速です。
元の質問の要点により直接的な別の回答を追加します。これより前の回答のほとんど (私自身のものを含む) は、時期尚早の最適化である可能性が非常に高いです。
1 秒あたり何千回もの malloc と free を実行する iPhone アプリがありますが、それらはアプリのプロファイルにも表示されません。
したがって、元の質問に対する答えはノーです。
パーティクルの数が増えない限り (またはその間にメモリ警告を処理しない限り)、再割り当てする必要はありません。比較のために、最後に malloc されたサイズを維持してください。
hotpaw2 が述べたように、最適化する必要がある場合は、より多くのスペースが必要な場合にのみ割り当てることで、おそらく次のように行うことができます。
particleCount = [particles count];
if (particleCount > allocatedParticleCount) {
if (vertices) {
free(vertices);
}
if (textures) {
free(textures);
}
vertices = malloc(sizeof(point3D) * 4 * particleCount);
textures = malloc(sizeof(point2D) * 4 * particleCount);
allocatedParticleCount = particleCount;
}
...オブジェクトのインスタンス化時に、allocatedParticleCount を 0 に初期化しました。
PS オブジェクトが破棄されたら、オブジェクトを解放することを忘れないでください。.mm ファイルの使用を検討し、頂点とテクスチャの両方にC++/Boost のshared_arrayを使用します。その場合、上記の free ステートメントも必要ありません。
その場合、おそらくそのメモリを保持し、再割り当てするだけで済みます。