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预处理器黑客的额外麻烦g_slice_new)？我打算在我的C++程序中使用GLib来处理INIish配置(GKeyFile)并获得对C++中不可用的数据结构的访问GHashTable,因此无论如何GLib依赖都无关紧要.
更快,值得它取决于你的应用程序.但他们应该更快.
除了速度之外还有另一个问题,即内存碎片和每块开销.GSlice离开malloc来处理大型或可变大小的分配,同时更节省空间地处理小型已知大小的对象.
Slice API大量借鉴了Sun Microsystems在20世纪80年代进行的研究，当时被称为slab分配。我找不到原始的研究论文，但这里有一个关于它的维基百科页面，或者你可以直接谷歌搜索“平板分配”。
本质上，它通过促进内存块的重用来消除昂贵的分配/释放操作。它还减少或消除内存碎片。因此，速度并不全是问题，尽管它也应该提高速度。
如果你应该使用或不使用 - 这取决于......看看 Havoc 的答案 - 他总结得很好。
更新1：
请注意，现代 Linux 内核将 SLAB 分配器作为选项之一，并且通常是默认值。g_slice()因此，在这种情况下，和之间的差异malloc()可能不明显。然而，glib 的目的是跨平台兼容性，因此使用 slice API 可以在一定程度上保证跨平台的一致性能。
更新2：
正如评论者指出的那样，我的第一次更新是不正确的。SLAB 分配由内核用来为进程分配内存，但malloc()使用了不相关的机制，因此malloc()相当于g_slice()Linux 上的声明是无效的。另请参阅此答案以了解更多详细信息。