私はマルチスレッドプラグインを開発中です。かなり大きなメモリブロック（> 10 MB）でfree（）を実行すると、プラグインを使用したアプリケーションが一時的に遅くなりすぎます。 （そのオーディオアプリ、オーディオスレッドはあまりにも時間がかかります）。 free（）が多くのCPUを使用しているか、他のスレッドの処理が長すぎるかどうかは分かりません。 madvice（）への呼び出しが多くの作業をしているようです。私はfree（）に多大な時間を要しています（32ビットモードで動作していないとき）。free（）他のスレッドをブロックし、システムの減速
いくつかの情報： OSX &プログラムをプラグイン10.8 64ビットが C++
継続する方法上の任意の提案は非常に歓迎されています。
もちろん、free()（これはC++で何らかの形式のdeleteにする必要があります）をやめることです。
プラグインがまだロードされていてアクティブ（または「実行中」）の間はメモリを解放しないでください。プラグインが不要になったときにリソースを解放してください。
古いバッファを解放した後に新しいバッファを再割り当てする必要がある場合は、既に割り当てられたメモリを再利用する方法を見つけてください。
+1同期リアルタイムビデオプレーヤーでこれをやったのです。 –
私はそれを行うことができたらいいと思います。私の記憶の必要条件は、選ばれたプリセットに大きく依存しています。 – jankoen
メモリを再利用する場合は、おそらくプレースメントnewを使用すると、free/deleteへの呼び出しを完全に取り除くことができます。
バッファのサイズが同じかそれほど近い場合は、空きが遅れて恩恵を受け、代わりにrealloc（）を使用すると便利です。これは扱いにくいことがあります。
大規模な割り当ての場合は、vm_allocate（）を使用します。これは長いmadvice（）を呼び出さないようです。
私はvm_allocate（）とそれに対応するvm_deallocate（）を使用しているので、メモリ解放呼び出しはすべて高速です。
おそらく、デバッグの目的でメモリが消去されるため、空き時間がかかる可能性があります。 –
プログラムをインストルメントできますか？OS Xでは楽器を使用するのがとても簡単です。それはあなたのプログラムが大部分の時間を費やしているところを教えてくれるでしょう。 – parry
リアルタイムの優先度の高いオーディオコールバックスレッドでは、メモリの割り当てや割り当て解除は避けてください。 [テクニカルQ＆A QA1467：CoreAudioのオーバーロードに関する警告]（https://developer.apple.com/library/mac/qa/qa1467/_index.html）の推奨事項を参照してください。 mallocの実装では、スレッドの安全性を確保するためにロックが必要です。 –