坑爹的stl

本文探讨了std::list::size()的性能问题,并指出其时间复杂度为O(n),而非通常认为的O(1)。此外,还讨论了__gnu_cxx::hashmap::begin()的效率问题,在某些情况下也会导致CPU占用率高。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

1) std::list::size() 是O(n)的

我会连接后端某个服务, 后端服务挂掉后, 我会堆积请求; 重连上之后会发送,使用std::list::size来进行不为空的判断或者log输出。

结果cpu 占了100%, 1秒发不了几个包。

最后通过log定位到了std::list::size()可能有问题, 阅读源码,确定是这个原因。

后来网上也看到类似的:http://blog.youkuaiyun.com/russell_tao/article/details/8572000


另外,合作部门的同事说:

1)  c++11的std::list::size是O(1) ? 我看源码不是这样哦? 仍然是O(n)

2) 使用deque做FIFO队列。 侯捷的stl源码剖析中说deque有性能问题,实现很复杂, FIFO使用deque也是非常浪费。



2) __gnu_cxx::hashmap::begin() 不是O(1)

begin成员函数是顺序扫描hashmap的bucket, 找到第一个非空的bucket。

当hashmap的bucket比较大(100w级别), 同时元素较少时, 同样非常吃cpu、且慢。

具体见 http://blog.youkuaiyun.com/aalbertini/article/details/38843673

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值