使用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