使用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;
}
{
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;
}
{
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