注： 使用的dlmalloc为2.8.3版本
使用GetTickCount()，测试1000000次的new/delete
分配空间大小为2的幂，依次递增
在Debug模式下
sgi-stl alloc > dlmalloc > ::operator new
在Release模式下
dlmalloc > sgi-stl alloc > ::operator new
以下数据为Release模式下测得
测试程序1
for (size_t n=0; n<Times; ++n)
{
Test *p = new Test;
delete p;
}
数据
---------
字节数 ::operator new sgi-stl alloc dlmalloc 次数
< 128 329 156 31 1000000
< 262132 1000 953 31 1000000
> 262132 984 969 15547 1000000
测试程序2
for (size_t n=0; n<Times; ++n)
{
Test *p = new Test;
}
数据
---------
字节数 ::operator new sgi-stl alloc dlmalloc 次数
1 422 94 32 1000000
64 484 156 94 1000000
128 547 219 157 1000000
262132 16 失败 844 1024
524264 94 失败 1532 1024
需要说明的是，sgi-stl alloc失败时竟然会报告：
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
O_O!
结论
---------
sgi-stl alloc在<=128 bytes下，成绩约为::operator new的一倍，否则与之相同
可怕的是dlmalloc，几乎都是常数级别
在大量new后马上delete的这种状况下，dlmalloc在<262132下行为同上，而一旦超过，则效率剧降，成绩为::perator new的15倍 =。=b
我想应该是跟算法有关（见侯捷老师的《池内春秋》）
当new时，现存的链表空间不足时，会重新分配构成新的，或者找其他几个“低一级”的要“连续的内存”，然后delete后又会“返还”？！导致的吧。
不管怎样，dlmalloc都会是我的最终选择，
Doug Lea 果然不是一般的强，一辈子在搞malloc的人，不一样，就是不一样！admire~
m(_ _)m
posted on 2006-01-10 15:31
千里马肝 阅读(752)
评论(4) 编辑 收藏