算法

　　一次性读文件

　　我已经测试过好几次了，一次性读取文件比一行一行读文件至少快五倍

　　记住O(N)

　　这时你要好好考虑算法的复杂度了。任何O(N2)的算法都不可取。

　　必要的时候可以通过空间来换时间。通常哈希表能节省不少时间。

　　并行处理

　　温习一下并行算法。这比等待单线程程序好很多。

　　可以考虑在GPU上跑程序。当然，内存和文件读取时间更可能是瓶颈。

　　内存、CPU、磁盘读取速度，谁是瓶颈，任务管理器知道。

　　优化核心代码

　　通常80%的时间在运行20%的代码。所以有空的话优化下经常经常执行的代码。

　　分布式保存

　　把分析结果存在一个文件中是一个很糟糕的决定。这会为后面处理带来很多麻烦。比如并行处理，文件过大等。

　　二进制方式保存中间数据

　　二进制方式存放通常能省一半的磁盘空间。这同时意味着减少一半的写硬盘时间和读硬盘时间。当然，还有文本转换时间。

　　还有个重要细节要注意：在Windows中，读写文件的方式要改成”rb”和”wb”。要不然莫名的Bug迟早要发生，但不一定能找到。

　　运行

　　Debug Vs Release

　　别忘了，最终运行时把编译方式换成Release。但是刚改完程序的话，建议先用Debug模式试跑一下。这样能定位运行时异常。

　　批处理

　　批处理是降低运行出错风险的很好的方式。因为你不确定程序能正常结束。所以一段一段执行程序是一个很好的选择。如果某个地主出问题的话就不用重新运行前面的程序了。

　　断言

　　当数据量很大时，很难保证输入是合法的。另一种情况是，数据是合法的，但我们欠考虑了。这时断言就显得很重要了。断言回增加运行时间，但总比花大量时间得到一个错误结果好。

　　记录运行结果到文件

　　前面提到，数据量很大时，很难保证程序正常结束。一般，很少人会坐在显示器旁监视输出结果。把运行情况定时记录到文件是非常必要的。

　　另外，不要忘了fclose();

　　附：64位编程问题

　　数据量很大时，内存通常是不够用的。有一个常识必须知道：32位程序的最大寻址空间是2GB。如果你要分配接近或者超过2G内存的话，试试64位程序吧。当然有两条件：64位的CPU，64位的操作系统。

　　下面是编写64位程序的一些经验

　　编译环境

　　如果是解释型语言，比如Python，则需要下载一个64位的Python解释器

　　如果是编译型语言，比如C/C++，则需要选择恰当的编译平台。

　　比如VS2010中，项目属性 => Configuration Manager => Platform => New => X64

　　内存

　　分配大数组，应该用malloc，而不是直接定义数组。

　　sizeof( int ) != sizeof( size_t )

　　64位程序中，数组下标应该换成size_t，常数也需要强制转换，比如 4GB = 4*(size_t)1000000000000

　　文件

　　fwrite一次性写入一个大于4GB的数组似乎有些问题。

　　分多次写入文件试试。