g_slice 真的比 malloc 快吗
GLib 文档建议使用 GLib Slice Allocator 而不是 malloc：
“对于新编写的代码，建议使用新的 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 依赖项无论如何都没关系。
The GLib docs recommend use of the GLib Slice Allocator over malloc:
"For newly written code it is recommended to use the new g_slice API instead of g_malloc() and friends, as long as objects are not resized during their lifetime and the object size used at allocation time is still available when freeing."
-- http://developer.gnome.org/glib/unstable/glib-Memory-Slices.html
But in practise is g_slice significantly faster than Windows/Linux malloc(faster enough to warrant the extra trouble of handling sizes and GLib's preprocessor hacks like g_slice_new)? I'm planning to use GLib in my C++ program to handle INIish configuration (GKeyFile) and to get access to data structures not available in C++ like GHashTable, so the GLib dependency doesn't matter anyway.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
速度是否足够快是否值得取决于您的应用程序。但他们应该更快。
除了速度之外还有另一个问题，那就是内存碎片和每块的开销。 GS切片
让 malloc 处理大型或可变大小的分配，同时更有效地处理已知大小的小对象。
Faster enough to be worth it sort of depends on your app. But they should be faster.
There is another issue besides speed, which is memory fragmentation and per-block overhead. GSlice
leaves malloc to deal with large or variable-size allocations while handling small known-size objects more space-efficiently.
Slice API大量借鉴了Sun Microsystems在20世纪80年代进行的研究，当时被称为slab分配。我找不到原始的研究论文，但这里有一个关于它的 维基百科页面 或者你可以直接谷歌搜索对于“板分配”。
本质上，它通过促进内存块的重用来消除昂贵的分配/释放操作。它还减少或消除内存碎片。因此，速度并不全是问题，尽管它也应该提高速度。
如果你应该使用或不使用 - 这取决于......看看 Havoc 的答案 - 他总结得很好。
更新 1：
请注意，现代 Linux 内核将 SLAB 分配器作为选项之一，并且通常是默认值。因此，在这种情况下，
g_slice()和malloc()之间的差异可能不明显。然而，glib 的目的是跨平台兼容性，因此使用 slice API 可以在一定程度上保证跨平台的性能一致。更新2：
正如评论者指出的那样，我的第一次更新是不正确的。 SLAB 分配由内核用来为进程分配内存，但
malloc()使用不相关的机制，因此声明malloc()等效于g_slice()< /code> 在 Linux 上无效。另请参阅此答案了解更多详细信息。Slice API heavily borrows from research conducted by Sun Microsystems in 1980s and it was called slab allocation back then. I could not find original research paper but here is a wikipedia page about it or you can just google for "slab allocation".
Essentially it eliminates expensive allocation/deallocation operations by facilitating reuse of memory blocks. It also reduces or eliminates memory fragmentation. So it is not all about speed, even though it should improve it as well.
If you should used or not - it depends... Look at Havoc's answer - he summarized it pretty well.
Update 1:
Note, that modern Linux kernels include SLAB allocator as one of the option and it is often the default. So, the difference between
g_slice()andmalloc()may be unnoticeable in that case. However, purpose of glib is cross-platform compatibility, so using slice API may somewhat guarantee consistent performance across different platforms.Update 2:
As it was pointed by a commenter my first update is incorrect. SLAB allocation is used by kernel to allocate memory to processes but
malloc()uses an unrelated mechanism, so claim thatmalloc()is equivalent tog_slice()on Linux is invalid. Also see this answer for more details.GSlice 实现在 2.76 中被删除，理由是普通内存分配器的性能得到了改进。现在，
g_slice_new()和g_slice_free()将仅调用g_malloc()和g_free()。因此，在新版本上两者没有区别。
参考：https://docs.gtk.org/glib/memory-slices.html< /a>
The GSlice implementation was removed in 2.76, citing improved performance of normal memory allocators. Now
g_slice_new()andg_slice_free()will just callg_malloc()andg_free().Therefore, there's no difference between the two on newer versions.
Reference: https://docs.gtk.org/glib/memory-slices.html