C ++内存分配机制性能比较（tcmalloc vs. jemalloc）

Question

我有一个分配大量内存的应用程序，我正在考虑使用比malloc更好的内存分配机制。

我的主要选择是：jemalloc和tcmalloc。 使用它们中的任何一个是否有任何好处？

在http://locklessinc.com/benchmarks.shtml中 ，一些机制（包括作者的专有机制 - 无锁）之间有一个很好的比较，它提到了每个机制的优点和缺点。

鉴于这两种机制都是积极的并且不断改进。 有没有人对这两者的相对表现有任何见解或经验？

Answer 1

如果我没记错的话，主要区别在于多线程项目。

两个库都尝试通过让线程从不同的缓存中选择内存来解除内存获取，但它们有不同的策略：

• jemalloc （由Facebook使用）维护每个线程的缓存
• tcmalloc （来自谷歌）维护一个缓存池，线程为缓存开发“自然”亲和力，但可能会改变

如果我没记错的话，这导致了线程管理方面的重要区别。

• 如果线程是静态的，则jemalloc会更快，例如使用池
• 创建/销毁线程时tcmalloc更快

还有一个问题是，由于jemalloc旋转新的缓存以容纳新的线程ID，突然出现线程突然将在随后的平静阶段留下（大部分）空缓存。

因此，我建议在一般情况下使用tcmalloc ，并为非常具体的用法保留jemalloc （应用程序生命周期内线程数的变化很小）。

Answer 2

我最近考虑过tcmalloc用于工作中的项目。 这是我观察到的：

• 在多线程设置中大量使用malloc的性能大大提高。 我在工作中使用了它，性能提高了近两倍。 原因是在这个工具中有一些线程在关键循环中执行小对象的分配。 使用glibc，性能会因为我认为在不同线程中锁定malloc / free调用之间的争用而受到影响。

• 不幸的是，tcmalloc增加了内存占用。 我上面提到的工具会消耗两到三倍的内存（用最大驻留集大小来衡量）。 由于我们实际上正在寻找减少内存占用的方法，因此增加的占用空间对我们来说是不可取的。

最后我决定不使用tcmalloc而是直接优化应用程序代码：这意味着从内部循环中删除分配以避免malloc / free lock争用。 （对于好奇，使用压缩形式而不是使用内存池。）

您的教训是，您应该使用典型的工作负载仔细测量您的应用程序。 如果你能负担额外的内存使用量，tcmalloc对你来说可能很棒。 如果没有，tcmalloc仍然有用，可以避免频繁调用跨线程的内存分配，从而了解您将获得的收益。

Answer 3

请注意，根据'nedmalloc'主页，现代操作系统的分配器现在实际上非常快：

“Windows 7，Linux 3.x，FreeBSD 8，Mac OS X 10.6都包含最先进的分配器，没有第三方分配器可能会在实际结果中显着改善它们”

http://www.nedprod.com/programs/portable/nedmalloc

所以你可能只是推荐你的用户升级或类似的东西:)

Answer 4

这里有关于分配器的非常好的讨论：

http://www.reddit.com/r/programming/comments/7o8d9/tcmalloca_faster_malloc_than_glibcs​​_open_sourced/

Answer 5

你的帖子没有提到线程，但在考虑混合C和C ++分配方法之前，我会调查内存池的概念.BOOST有一个好的。

Answer 6

你也可以考虑使用Boehm保守的垃圾收集器 。 基本上，你每更换malloc在你的源代码GC_malloc （等等），并且不怕麻烦打电话free 。 Boehm的GC不会比malloc更快地分配内存（它大致相同，或者可以慢30％），但它具有自动处理无用内存区域的优势，这可能会改善您的程序（并且当然可以简化编码，因为你不再关心免费）。 而Boehm的GC也可以用作 C ++分配器。

如果你真的认为malloc太慢了（但是你应该进行基准测试;大多数malloc -s需要不到几微秒），如果你完全理解程序的分配行为，你可以用你的特殊分配器替换一些malloc-s（例如，可以使用mmap以大块的形式从内核获取内存并mmap管理内存。 但我相信这样做很痛苦。 在C ++中你有分配器概念和std::allocator_traits ，大多数标准容器模板接受这样的分配器（参见std::allocator ），例如std::vector的可选第二个模板参数等...

正如其他人所说，如果您认为malloc是一个瓶颈，您可以分块（或使用竞技场）或仅在数组中分配数据。

有时，实现专门的复制垃圾收集器 （对于您的某些数据）可能会有所帮助。 或许考虑一下MPS 。

但不要忘记， 过早优化是邪恶的 ，请对您的应用程序进行基准测试和分析，以准确了解时间的流逝。