首先感谢 lalor的读书笔记。
使用 v_july 教科书版本。
使用acm 文件操作方法，重定向 （所谓）
| 完成 | 海量测试框架的摸索 | 用 freopen |
| todo | 还没有 实现产生不同的随机数 | 解决方法：珠儿 |
| Todo | 还没有 将产生随机数的 模块单独出来 ，这样紧接着 读入文件流 | 下一个月说 |
| todo大 | 还没有 比较 珠儿5块代码的 |
|
| todo | 在 http://blog.csdn.net/lalor/article/details/7370542 作者处还有 优先级队列的代码 |
|
|
| 比较结果分析说明（windows平台），有统计意义的，有曲线更好
以后有时间，来个统计学 意义的比较。。多次操作求平均值 如： 1k 10k,100k. 10w...每次10次，来个performance
| 发现跟linux 差一个数量级 why? 还有系统的sort函数优化得不错，比 自定义heap快。 |
| 完成 | 教科书版本 heapsort, 分清楚 up..down 和 build堆的关系 |
|
|
| 在我手机上 有个 简化版本 堆算法的演示图（6张图） |
|
一.自定义堆算法和 标准sort调用 结果 比较
由于数据量较大，使用命令行比较
使用 gnu diff 在 windows 下面比较 两个大文件输出，没有差异(比较了没有任何输出， 看了下 鸟哥 diff，这就是 没有差异)
二. 增大测试数据的方法
2.1、内存空间分析
使用宏定义数组的大小。范围期望达到10w..
如下：
#define MAX 100000 //
就是需要1m*4的内存对于一个int数组， 那么两个数组理论上8m ,我分别尝试了 9m到20m都报溢出。
| 66 | 下一次研究下 栈上变量 能够申请的最大值。 这里为什么会戳粗 |
现象如下：
; Find next lower page and probe
cs20:
sub eax, _PAGESIZE_ ; decrease by PAGESIZE
test dword ptr [eax],eax ; probe page.
jmp short cs10
代码见证.exe 中的 0x00412347 处未处理的异常: 0xC00000FD: Stack overflow
期间尝试方法：如下：
2.
。 下面尝试少用一个数组（这里让我想起 v_july的算法里 对sort的使用 有个bug） 或者是 将两个大数组 变成全局变局变量，本次采用全局变量方案
| 66 | 下次有空 尝试下，大数组能够申请的上限 |
问题暂时解决，到100w，没有任何压力
规模：1000 , time cost 0 ms
| USE SORT 规模：1000 , time cost 0 ms | 以两次输出为对比，第一行表示堆排序，第二行表示std:sort |
|
| 对于1k,小数据。。 没有丝毫压力 |
规模：10000 , time cost 0 ms
USE SORT 规模：10000 , time cost 16 ms
规模：10000 , time cost 0 ms
USE SORT 规模：10000 , time cost 15 ms
规模：100000 , time cost 125 ms
USE SORT 规模：100000 , time cost 110 ms
规模：100000 , time cost 109 ms
| USE SORT 规模：100000 , time cost 109 ms | 10w两次测试，发现有时偏大,有时偏小。充分说明多次测试必要 |
规模：200000 , time cost 250 ms
USE SORT 规模：200000 , time cost 203 ms
规模：200000 , time cost 266 ms
USE SORT 规模：200000 , time cost 218 ms
规模：200000 , time cost 266 ms
USE SORT 规模：200000 , time cost 203 ms
规模：200000 , time cost 266 ms
USE SORT 规模：200000 , time cost 218 ms
规模：200000 , time cost 250 ms
| USE SORT 规模：200000 , time cost 219 ms | 如上，数据规模 20w时，系统sort有优势！！ |
|
| Why ?? 是不是小数据， 这里需要画个曲线比较一下就好 |
| 66 | 特别说明：以上是 用的堆栈，到20w 就堆栈溢出了。 |
|
| 上下数据：没有对比性。。 下面使用全局变量申明。 |
规模：300000 , time cost 421 ms
USE SORT 规模：300000 , time cost 328 ms
规模：400000 , time cost 563 ms
USE SORT 规模：400000 , time cost 421 ms
规模：500000 , time cost 703 ms
USE SORT 规模：500000 , time cost 516 ms
规模：600000 , time cost 875 ms
USE SORT 规模：600000 , time cost 578 ms
规模：700000 , time cost 1063 ms
USE SORT 规模：700000 , time cost 718 ms
规模：800000 , time cost 1157 ms
USE SORT 规模：800000 , time cost 844 ms
规模：900000 , time cost 1344 ms
USE SORT 规模：900000 , time cost 922 ms
规模：100000 , time cost 109 ms
USE SORT 规模：100000 , time cost 109 ms
规模：1000000 , time cost 1531 ms
USE SORT 规模：1000000 , time cost 1062 ms
规模：1000000 , time cost 1516 ms
USE SORT 规模：1000000 , time cost 1046 ms
规模：1000000 , time cost 1516 ms
| USE SORT 规模：1000000 , time cost 1046 ms | 比较完以上结果，发现sort没有丝毫弱势？ Why? |
|
| 唯一安慰的是，都还是一个数量级。 在作者博客下面 ubutu,未知硬件，未知内存负载下，是80ms 排完 100w.. |