Chinaunix首页 | 论坛 | 博客
  • 博客访问: 2699823
  • 博文数量: 361
  • 博客积分: 1241
  • 博客等级: 中尉
  • 技术积分: 4924
  • 用 户 组: 普通用户
  • 注册时间: 2011-01-27 06:48
个人简介

下死功夫,动活脑筋;读好书,交益友

文章分类

全部博文(361)

文章存档

2019年(16)

2018年(23)

2017年(67)

2016年(45)

2015年(51)

2014年(58)

2013年(53)

2012年(42)

2011年(6)

分类: C/C++

2015-01-23 14:57:10

继续看大牛的blog
这里多说一点在C++中,我们可能会使用线程安全的智能指针AutoPtr或是别的一些容器,只要是线程安全的,其不管三七二十一都要上锁,上锁是个成本很高的操作,使用AutoPtr会让我们的系统性能下降得很快,如果你可以保证不会有线程并发问题,那么你应该不要用AutoPtr。我记得我上次我们同事去掉智能指针的引用计数,让系统性能提升了50%以上
首先我说明一下,AutoPtr 我没见过,应该是autoptr,但是autoptr,根本没有多线程版本。并且autoptr也是模版展开,对性能影响不大,新版的c++中,autoptr已经被废弃了。

说的如果是shared_ptr,也很诡异,shared_ptr的引用计数是采用atomic,性能不至于这么差啊!
确实使用shared_ptr会多申请一块内存,shard_ptr需要一个refCount,但是用make_shared会减少一次new。
不要小看程序的内存分配。malloc/realloc/calloc这样的系统调非常耗时,尤其是当内存出现碎片的时候。我以前的公司出过这样一个问题——在用户的站点上,我们的程序有一天不响应了,用GDB跟进去一看,系统hang在了malloc操作上,20秒都没有返回,重启一些系统就好了。这就是内存碎片的问题。这就是为什么很多人抱怨STL有严重的内存碎片的问题,因为太多的小内存的分配释放了。有很多人会以为用内存池可以解决这个问题,但是实际上他们只是重新发明了Runtime-C或操作系统的内存管理机制,完全于事无补。当然解决内存碎片的问题还是通过内存池,具体来说是一系列不同尺寸的内存池(这个留给大家自己去思考)。
对于malloc确实耗时,但你要看应用场景,跟STL没关系,可以用的allocator有很多,例如TBB allocator,google allocator,都是久经考验的企业级产品。

阅读(2200) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~
评论热议
请登录后评论。

登录 注册