1

我目前正在使用 Dirac(OSStatus) readFloatsConsecutive:(SInt64)numFrames intoArray:(float**)audio函数从文件中读取音频浮点数。我创建了一个浮点指针**

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

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

并将它传递给 Dirac 函数，当所有浮点数都被分配时，我会得到一个巨大的内存峰值。

在仪器中，我得到了大约 90MB 的峰值，并且由于某种原因，这个应用程序仍然在设备上运行。

例如 15839544 * 2 个浮点数会导致这些巨大的峰值吗？

怎么会占用这么多内存？是虚拟内存吗？我没有看到任何虚拟机分配。

我看不出加载单个文件（例如 5MB 音频文件）如何导致内存中出现如此巨大的峰值。

4

2 回答 2

3

例如 15839544 * 2 个浮点数会导致这些巨大的峰值吗？

是的，一点没错。一个浮点数是 4 个字节，因此两个 1580 万个浮点数的数组总共约为 120 MB。

至于您如何从 5 MB 的输入文件中得到这个：音频压缩是一件了不起的事情。:)

于 2012-08-08T22:27:57.607 回答
1

它可能是虚拟内存 - 尽管不是通常（错误）理解的方式。

虚拟内存是映射到进程中的可用地址空间。它可能会或可能不会用内存的物理页备份。

访问未如此备份的页面会导致页面错误，然后内核以多种方式之一提供服务：

  • 分配一个新的归零页面
  • 分配页面并用内存映射文件的页面填充其内容
  • 分配页面并从页面文件中填充其内容
  • 不执行上述任何操作并终止应用程序

因此，malloc()对于大量内存（大于可用的物理页面）往往会成功，而操作系统有足够的 RAM 来分配页面描述符以将虚拟空间映射到进程中（尽管如果超过资源限制，它可能会下降）观点）。尝试实际写入分配的空间会逐渐将物理页面拉入进程。

您指示的大小实际上是 ~128MB 内存。您不太可能在 iDevice 上使用这么多物理 RAM，所以我认为我们可以假设它并没有全部被使用。您可能可以获得页面错误数量的统计信息 - 这将使您对使用的数量有一个很好的了解（大概是每页 4kB）。

我希望您的进程的 VM 统计信息包括此分配。

于 2012-08-08T22:42:51.767 回答