stl::list的size实现太有问题啦

这几天做一个程序,在遍历一个100万个数据的LIST的时候非常非常慢,我把可能出现消耗时间都打印出来了,死活都找不到消耗时间的地方在什么地方。

最后盯上了判断size()等于一个值的地方,因为就剩下这个地方了,就打上了时间,结果发现竟然就是此处。一个size方法竟然消耗了0.02秒。注释掉后就一切正常了。最后的解决办法只好我帮助它来计数。

写了个小程序,发现list的size果然消耗时间,不过幸运的是empty不消耗时间。

而最幸运的是最常用的map的size并不消耗时间。

有空看看源码吧,难道每次size都要从头计算一次吗?

#include<list>
#include<sys/time.h>
#include<stdio.h>
using namespace std;

void p1()
{
struct timeval start;
gettimeofday(&start, 0);
printf("%u,%u\n",start.tv_sec,start.tv_usec);

}

int main()
{
list<int> lista;
p1();
for(int i=0;i<10000;i++)
lista.push_back(1);

p1();

for(int i=0;i<1000;i++)
{
lista.size();
lista.pop_front();
}
p1();

for(int i=0;i<1000;i++)
lista.pop_front();
p1();
return 0;
}

结果:
1238513193,693237
1238513193,695993
1238513193,795487
1238513193,795597

只是1W个数据就这样慢的,100W的数据更是慢的惊人。

--------------------------------------------------------------------

查了一下源码,果然是每次重新计算的,难道就为了节省4字节的空间?

size_type size() const {
    size_type __result = 0;
    distance(begin(), end(), __result);
    return __result;
}

时间: 2024-10-10 17:25:22

stl::list的size实现太有问题啦的相关文章

openstack image virsual size 10G太大

处理方法如下: You need to convert the qcow2 image to raw qemu-img convert -O raw guest.img guest.raw Then resize the raw file qemu-img resize guest.raw 3G Then convert it back to qcow2 qemu-img convert -O qcow2 -o compat=0.10 guest.raw guest.img Then run t

v.size() return size_t not int 返回无符号整型数

In the C++ STL, the vector size() function return size_t, which is unsigned int, not int. So imagine this, define an empty vector<int> v, and v.size() should be 0, and you have a for loop, and has an end condition is v.size() - 1, which is 429496729

Iterator模式(C++迭代器模式)

基本上来说,Iterator模式并没有什么可多说得,在STL中见得实在太多了,一般用于遍历数据结构,其实现也相对简单. 代码如下: ////////////////////////////////////////////////////////////////////////// // author: Jeson Yang //date:2014.12.10 //file:main.cpp /////////////////////////////////////////////////////

Python2 基本数据结构源码解析

Python2 基本数据结构源码解析 Contents 0x00. Preface 0x01. PyObject 0x01. PyIntObject 0x02. PyFloatObject 0x04. PyStringObject 0x05. PyListObject 0x06. PyDictObject 0x07. PyLongObject 0x00. Preface 一切皆对象,这是Python很重要的一个思想之一,虽然在语法解析上有些细节还是不够完全对象化,但在底层源码里,这个思想还是贯穿

AGG第七课 内存分配策略

说明 AGG采用new/delete函数操作堆内存,有时候并不是最佳的选择.另一方面,STL的内存分配策略太繁琐,因此没有采用.在agg_allocator.h文件中描述目前内存分配策略: template<class T> struct allocator { static T* allocate_array(unsigned size) { return new T [size]; } static void free_array(T* v, unsigned) { delete [] v

【实习记】2014-08-16向cgicc拿cookie无果只能自己来

功能:登录时检验从数据库取出的帐号密码,生成token放到数据库中,最后设置cookie实现登录. 在操作cookie过程中cgicc方面有太重的stl感,具体来说,太抽象了. 源码有关demo文件夹有官方示例: const_cookie_iterator iter; for(iter = env.getCookieList().begin(); iter != env.getCookieList().end(); ++iter) { cout << tr().set("class&

IxEngine开发笔记

第一回 开篇 D3D渲染流程简介 开发这个3D engine已经两年半了,从06年8月刚开始统计的4万多行,到今年7月份的21万多行,有一些感慨,感觉有那么点成就感,不过更多的是惴惴之心:这些代码可以很好的在一起工作吗,足够快吗?bug肯定不少,因为测试的强度毕竟不高,这还不是最重要,架构上会不会有致命的疏忽的地方?会不会在未知的需求面前不堪一击?前些日子看了看两年前写的代码,觉得不满意的地方很多,代码写出来的一瞬间就开始贬值,两年多时间,也的确该贬得差不多了,有心要 重写,似乎又没多少时间,接

并没有什么卵用...

还是不要乱用STL了吧.毕竟炸了这么多回了. MARK: STL的各种容器,因为内存是动态分配的,所以效率会比较低,内部实现也不如手写(RB_Tree搞得我跟2B一样,STL还说线段树太基础,用RB_Tree好了,然而效率低啊!map, set, etc.)各种数据结构也跟炸了一样(因为要考虑各种各样的问题,效率也是低到够可以!queue, stack, etc.)

32位平台代码向64位平台移植

1背景描述 从苹果A7处理器开始,就支持着两种不同的指令集:第一种为原有处理器所支持的32-bit ARM指令集,第二种为崭新的64-bit ARM体系结构.这种64-bit体系结构拥有更大的地址空间,最大支持16GB内存,同时它一次性可提取64位数据,比32-bit体系提高了一倍.现如今,苹果的LLVM编译器已经能够充分支持64-bit指令集. 正如苹果A7处理器一样,支持64-bit指令集的处理器已经很普遍了,如AMD公司的AMD-64.Intel公司的EM64T及IA-64.处理器属于硬件