使用Tcmalloc的性能测试结果报告，比malloc有大幅度提高

rain_fish

在实际环境下测了一下。
线程池服务器，16核，20线程，总体性能提高大约30%。
yulihua49 发表于 2011-07-12 13:24

    好东西。。。。，不过貌似用的人比较少

yulihua49

好东西。。。。，不过貌似用的人比较少
rain_fish 发表于 2011-10-20 13:51

    貌似可靠性比较差。有时core dumpped，在tc_ 里。

egmkang

貌似可靠性比较差。有时core dumpped，在tc_ 里。
yulihua49 发表于 2011-10-21 14:35

那是你代码的问题吧
我们这边30W代码,用也没啥问题

tao_627

相当不错，正考虑在程序中使用

einsnabuck

测试不严格.应该是申请了,再往里面写一些随机内容后再释放.

fly3ds

貌似不错。我在freebsd里jemalloc资料里看到tcmalloc的。想当年，我们用malloc用的特别happy的时候，哪里知道现在多线程多处理器有这么多。可能没过几年，新硬件的诞生，这些tcmalloc、jemalloc又不行了，需要又搞出一个malloc来适应新的硬件技术。

看你这结果很诱人，不过，我还是要说，尽量少用，我认为malloc类的好处是直观上没有浪费内存，需要多少malloc多少；用栈内存的方式，你一次需要多准备些内存，比如申请个int a[200]，实际中可能用到了123，剩下的200-123浪费了。

其实不然，malloc这类内存分配带来问题远比他的好处要多；首先，malloc分配内存要比栈内存要慢，慢很多很多，就这一条，你们就应该放弃使用malloc以及任何内存分配函数；其次，你要记得free。没有free会如何？内存泄露？可能吧，但是如果内存不紧张，泄漏点也没关系；最怕的是程序不仅仅是”内存泄露“，而是segmantation falut。

仅仅不free就会导致segmatation fult吗？ 各种malloc的作者不会承认这一点，人们只会传说Glibc使用广泛，是Linux系统上编写C程序必不可少的工具、jemalloc tcmalloc适应了多处理器多线程编程环境。但是在我实际的使用中，却出现过这个问题。我曾经封装过一个多进程多线程函数，这个多进程线程池模型有点复杂，每个线程中可能都malloc了一些东西，主进程中可能也有。最后我被自己的程序搞崩溃了。

一句话：尽量少用、甚至不用malloc内存分配函数，除非这个malloc函数是你自己实现的，一举一动了如指掌。


谈到这里，我顺带提下C++ STL的各种分配器，new/delete之类的东西，以及boost里的各种东西，他们可以作为示例程序出现在各种图书里，可以占据某某会议的大幅度时间，但是他们不应该出现在你的程序里，特别是那些真的运行为人们提供各种服务的程序。

fly3ds

回复 12# yulihua49

malloc用多了也会出现这种情况。

yulihua49

fly3ds 发表于 2013-10-10 20:09
谈到这里，我顺带提下C++ STL的各种分配器，new/delete之类的东西，以及boost里的各种东西，他们可以作为示例程序出现在各种图书里，可以占据某某会议的大幅度时间，但是他们不应该出现在你的程序里，特别是那些真的运行为人们提供各种服务的程序。 ...

观点新颖但无法实现。

cxytz01

回复 16# fly3ds

那用什么？

没得用了。

brk, sbrk?


   

fly3ds

cxytz01 发表于 2013-10-16 00:37
回复 16# fly3ds

那用什么？

尽可能用数组int b[100], 而不要用int * b = (int *)malloc(sizeof(int) * 100);    数组的速度要比malloc快很多, 数组长度越大快的就越明显.   数组是语言核心, 用了这么多年, 被这么多人用, 几乎每个函数都会用, 从来没听说会出现什么问题. 要说有什么问题,那就是函数里的数组很大, 又递归调用多次超过过了系统用户栈的大小限制,  甚至超过过了实际的物理内存...  

用户栈大小限制是可以更改的. Windows系统上我不知道怎么改, Linux Solairs FreeBSD上可以通过ulimit取消大小限制. 也可以通过系统调用setrlimit来取消限制.

或者干脆用全局变量数组. 全局变量大小没听说会有什么限制,  我猜测只有实际可用的物理内存限制吧.

brk,  sbrk是另一个选择, 我认为用这两可能比malloc/free好一些. 但还是比不上用数组.