在什么情况下静态分配比动态分配更好？

Question

我正在做一些制作Xara Xtreme的决定，这是一个开源的SVG图形应用程序。他们的内存管理决策对我来说非常有趣，因为我天真地认为按需动态分配是编写面向对象应用程序的方式。

文档中的解释是

  

    

静态分配如何才能有效？

         

如果您习惯于大型动态数据结构，这可能看起来很奇怪     给你。首先，我们所有的对象（和     因此分配大小）要小得多     （平均而言）比每个动态区域     在诸如的程序内分配     印象。这意味着     可能会有很多漏洞     在记忆中，它们很小。也，     我们有更多的分配对象     在记忆中，因此这些洞     很快就会被填满此外，     虚拟内存管理器将释放出来     任何不包含的内存页面     分配并回馈这个记忆     到操作系统，以便它可以     再次使用（由我们或通过     另一项任务）。

         

我们受益匪浅     每当我们分配的事实     以这种方式记忆，我们没有     移动任何记忆。这证明了     也是ArtWorks的瓶颈     有很多小的分配使用     同时。 more

  

简而言之，存在大量小对象以及需要防止内存移动是选择静态分配的原因。我对上述原因并不清楚。

虽然这谈到静态分配，但我从粗略看一下代码看到的是，在应用程序启动时动态分配内存块并保持活动直到应用程序结束，大致模拟静态分配。

你能解释静态分配在什么情况下比按需动态分配更好，以便将其视为严肃应用中的主要分配模式？

Answer 1

它更快，因为您可以避免调用系统例程来管理存储的开销。 malloc()维护一个堆，因此每个请求都需要扫描一个适当大小的块，可能需要调整块大小，更新块列表以将此块标记为已使用，等等。如果要分配大量小对象，这种开销可能过高。使用静态分配，您可以创建分配池，只需维护一个简单的位图来显示正在使用的区域。这假定每个对象的大小相同，因此您通常会为每个对象类型创建一个池。

Answer 2

简而言之，除了为函数本身和其他只读类型的内存分配的空间之外，实际上没有静态分配这样的东西。 （如果你感兴趣的话，做一个只有汇编的“gcc -S”并寻找所有的内存块。）如果你正在创建和破坏对象，你就是动态分配。话虽如此，没有什么可以阻止你严格控制分配机制本身。

这就像mallinfo（）和mallopt（）这样的函数用于控制malloc（）如何发挥其魔力。但是，这对你来说甚至可能都不够好。如果您知道所有块的大小都相同，则可以更有效地分配和释放。如果你知道你有3种尺寸的东西，你可以用自己的分配器保留3个内存区域。

除此之外，您还有运行时的情况，其中进程没有足够的空间并且需要向操作系统询问更多内容 - 这涉及比仅增加数组索引更昂贵的系统调用。在unix上，它通常是brk（）或sbrk（）等。这可能需要宝贵的时间。

另一种罕见的情况是，如果你需要多次分配东西。就像3个线程需要共享信息一样，只有当所有3个线程都发布时它才会被释放。这是非标准的，通常不会被典型的mallopt（）甚至pthread特定的内存或互斥锁/信号量锁定的块所覆盖。

因此，如果您遇到高速优化问题或者您正在嵌入式系统上运行，您需要从可用内存中挤出所有内容，那么“静态分配”或至少控制分配机制可能是要走的路。