1

現在、Diracの(OSStatus) readFloatsConsecutive:(SInt64)numFrames intoArray:(float**)audio関数を使用してファイルからオーディオフロートを読み取っています。floatのポインタを作成します**

arrayToFill = malloc(channelCount * sizeof(float*));

for(int i = 0; i < channelCount; ++i)
{
    arrayToFill[i] = malloc(frameCount * sizeof(float));
}

そしてそれをディラック関数に渡すと、すべてのフロートがマロックされたときに大量のメモリスパイクが発生します。

楽器では、約90MB増加するスパイクが発生しますが、何らかの理由で、このアプリは引き続きデバイス上で実行されます。

たとえば、15839544 * 2つのフロートがこれらの大規模なスパイクを引き起こしますか？

どうしてそんなに多くのメモリを使うことができるのでしょうか？仮想メモリですか？VMの割り当てが表示されません。

たとえば5MBのオーディオファイルの単一のファイルをロードすると、メモリにこのような大規模なスパイクが発生する可能性があるかどうかはわかりません。

4

2 に答える 2

3

たとえば、15839544 * 2つのフロートがこれらの大規模なスパイクを引き起こしますか？

そのとおり。フロートは4バイトであるため、1個あたり1580万個のフロートの2つのアレイは合計で約120MBになります。

5 MBの入力ファイルからこれをどのように仕上げるかに関しては、オーディオ圧縮は驚くべきことです。:)

于 2012-08-08T22:27:57.607 に答える
1

これはおそらく仮想メモリですが、一般的に（誤）理解されている方法ではありません。

仮想メモリは、プロセスにマップされた使用可能なアドレス空間です。物理的なメモリページでバックアップされる場合とされない場合があります。

それほどバックアップされていないページにアクセスすると、ページフォールトが発生し、カーネルは次のいずれかの方法でサービスを提供します。

  • 新しいゼロ化されたページの割り当て
  • ページを割り当て、その内容をメモリマップトファイルのページで埋める
  • ページの割り当てとページファイルからのコンテンツの入力
  • 上記のいずれも行わず、アプリケーションを終了します

したがって、malloc()大量のメモリ（使用可能な物理ページよりも大きい）の場合は成功する傾向がありますが、オペレーティングシステムには、仮想空間をプロセスにマップするためのページ記述子を割り当てるのに十分なRAMがあります（ただし、これでリソース制限を超えると低下する可能性があります）点）。割り当てられたスペースに実際に書き込もうとすると、物理ページが徐々にプロセスに引き込まれます。

指定するサイズは、実際には最大128MBのメモリです。iDeviceでこれほど多くの物理RAMを使用できる可能性はほとんどないため、すべてが使用されているわけではないと考えられます。ページフォールトの数の統計を取得できる可能性があります。これにより、使用量（おそらく、ページあたり4kB）の良いアイデアが得られます。

プロセスのVM統計にこの割り当てが含まれていると思います。

于 2012-08-08T22:42:51.767 に答える