前阵子做的一个信令统计分析的项目，数据量实在太大了，信令日志入库之前需要根据LAC按地市切割之后分别入库，考虑到性能决定还是用C++写个小程序来切割，平台是Server2003，所以就拿VC6来做，不过对于MFC那些类都不太熟，也懒得去查，所以主程序基本上就是C写的，不过考虑到性能，不能一行一行读，还得有个buffer一次性读过来，然后处理，结果弱爆了，就这么一小程序半天也没搞定，总是有异常，而且错误都不知所云，debug也找不着个所以然来。最后一怒之下写了个java，用的BufferReader/Writer，半个小时就搞定，在笔记本上试了一下，切一个1G的文件用了49秒，也就是说读写都是20多MB/s，考虑的硬盘的速度，提升的空间已经不太大了。
不得不吐槽一下，VC6是我用过最烂的IDE，没有之一。哪天要是能摆脱Visual Studio我就去搞个mac去。
Buffer的大小是1MB，太大了对于速度也没多大影响，白白占用内存而已
周五整理语音服务端的程序，发现原来在程序启动的时候导入黑名单到内存（CMap）的那行代码被注释掉了，一看类实现发现查找黑名单也改成了实时查数据库的方式，于是试着去掉注释执行了一下，结果导入黑名单整整花了1000秒，怪不得要去掉呢；可是一看数据库里面也就是29万条记录，这个也不应该这么慢啊
首先想到的会不会是CMap在频繁的reallocate以至于耗费太多时间，一看这个类里头还真有个函数叫InitHashTable，果然MSDN里面写到：
For best performance, the hash table size should be a prime number. To minimize collisions, the size should be roughly 20 percent larger than the largest anticipated data set.
调用之后发现时间提高到了70秒，感觉还是不够快，应该也就是几秒的事儿，于是继续看代码。
果然看到原来的代码再用ADO读取SQL Server数据的时候为了简单起见，所有的代码打开数据库的时候用的都是一样的参数，而这里显然是只读的，所有游标打开的时候不需要是adOpenDynamic，用adOpenForwardOnly就足够了，再执行一看时间提高到了4秒，这些算是靠谱了。