g_slice真的比malloc快吗？

Question

GLib文档建议在malloc上使用GLib Slice Allocator：

  

“对于新编写的代码，建议使用新的g_slice API而不是g_malloc（）和朋友，只要对象在其生命周期内没有调整大小，并且在分配时使用的对象大小在释放时仍然可用。”    - http://developer.gnome.org/glib/unstable/glib-Memory-Slices.html

但实际上g_slice明显快于Windows / Linux malloc（速度足以保证处理大小的额外麻烦和GLib的预处理器hack如g_slice_new）？我打算在我的C ++程序中使用GLib来处理INIish配置（GKeyFile）并访问C ++中不可用的数据结构，如GHashTable，因此无论如何GLib依赖都无关紧要。

Answer 1

足够快，值得它取决于你的应用程序。但他们应该更快。

除了速度之外还有另一个问题，即内存碎片和每块开销。 Gslice上 使malloc处理大型或可变大小的分配，同时更节省空间地处理小型已知大小的对象。

Answer 2

Slice API大量借鉴了Sun Microsystems在20世纪80年代进行的研究，当时它被称为slab分配。我找不到原始的研究论文，但这里有一个wikipedia page，或者你可以谷歌“平板分配”。

本质上，它通过促进内存块的重用来消除昂贵的分配/解除分配操作。它还减少或消除了内存碎片。所以速度并不是全部，即使它也应该改进速度。

如果你应该使用或不使用 - 这取决于......看看Havoc的答案 - 他总结得很好。

更新1：

请注意，现代Linux内核包含SLAB分配器作为选项之一，它通常是默认选项。因此，在这种情况下，g_slice()和malloc()之间的差异可能无法察觉。但是，glib的目的是跨平台兼容性，因此使用slice API可以在某种程度上保证跨不同平台的一致性能。

更新2：

正如评论者指出的那样，我的第一次更新是不正确的。内核使用SLAB分配为进程分配内存，但malloc()使用不相关的机制，因此声称malloc()等效于Linux上的g_slice()无效。有关详细信息，另请参阅this answer。