最近一周比较忙，次要的任务内容是在做一个叫“键盘精灵”的东西，简单来讲就是将很多数据放到内存中，对这些数据进行快速检索，然后找出依据输入条件最婚配的10条记录并予以展现。具体和下面两款炒股软件的相关功用类似：

数据以文本方式存在文件中，且数据量较大，有近20万条，每一条记录有几个字段，以分隔符分割。当时使用的是6万条记录的测试数据，文本文件将近10M，这个模块加载到内存并建立缓存之后，大概会占用将近70-80M的内存。自我接手当前，次要的任务就是降低内存耗费和提高婚配效率。

一、避免创建不必要的对象

拿到代码后，第一步就是看设计文档，然后断点一步一步的看代码，大概明白了逻辑之后，发现思路有一些问题。之前的代码处理流程思路大概是下面这样的：

1.将文件读取到内存，实例化

2.依据条件对文件进行检索，并存储到结果集1中

3.对结果集1中的结果进行婚配度计算，并存储到结果集中2

4.按对结果集2进行婚配度排序，取最婚配的10条记录，然后前往

这个过程中规中矩。但是其中有很多问题，最大的问题是，临时变量存储了太多的两头处理结果，而这些对象在一次查询完成后又马上丢弃，大量的临时对象带来了很大的GC压力。举例来说，当用户在输入框中输入1的时候，假设使用Contains来婚配，那么从6万条记录中找出包含1的记录可能有4万多条，然后需求把这4万多条记录存储在临时变量中进行处理，进一步计算这4万条记录的婚配度，然后存储到一个类似KeyValuePair的集合中，key为婚配度，然后对这个集合按Key进行排序，然后取前10条最优记录。可以看到，两头创建了大量的临时变量，使得内存剧增，大量临时对象创建之后马上会被回收，GC压力山大。

而在设计文档中，只需求前往最最婚配的10条记录，之前的处理方案中似乎并没有留意到这一点。所以接手后，第一步就是对上面的处理过程进行精简。精简后如下：

将文件读取到内存，实例化

依据条件对文件进行检索，如果存在，则：

计算婚配度。

以婚配度为Key，存储到只要11个容量的SortList中。

如果SortList集合添加记录后大于10个，则移除最后面一个元素，一直保持着前10个最小（婚配度最优）的记录。

遍历完成之后，前往这个集合对象

经过这一修正，减少了大量临时数据对内存的占用，整个过程中，我只是使用一个容量为11的SortList结构存储两头的过程，每一次插入一个元素，SortList帮我们排好序，然后移除最不婚配的那一个，也就是最后一个元素(从小到大排序，越婚配，值越小)。这里面的耗费次要是SortList的插入，内部排序和移除记录。 说到这里在选择SortList还是SortDictionary的问题上纠结了一下，于是又找了些材料，SortDictionary在内部使用红黑树实现，SortList采用有序数组实现， 在内部排序都为O(logn)的前提下，SortDictionary的O(logn)插入及删除元素的时间复杂度优于SortList，但是SortDictionary会比SortList占用更多内存。基本来说这是一个查询速度和内存分配之间的平衡，由于这里只需求存储11个对象，所以两者相差不大。其实即便没有这种结构，本人也可以实现的，无非就是一个集合，每次添加一个，排好序，然后将最大的那个移除。.NET使用起来方便是由于有很多这些强大的内置数据结构。

经过上面这个小小的修正，内存占用一下子降低了1倍，从原来的70-80M，降低到了30-40M，其实这就是降低内存开销的一个最基本的准绳，那就是避免创建不必要的对象。

二、优化数据类型及算法

越到后面内存的降低越来越困难。细心看了代码之后，除了上面之外，代码中也有一些其他问题，比如，一开始就将大量的对象实例化到内存中，然后不断保存。每一条记录中的信息比较多，但真正有用的用于搜索婚配的只要下面四个字段，但是全体的实例化会将其他没有用的字段也一并序列化进去了。导致很多内存被无用的字段占用。

“股票代码 股票中文名 中文拼音 市场类型 ……

600000 浦发银行 PFYH 上证A股 ……”

所以第一步就是在内存中只存放需求检索的上面四个关键字段，每一条记录刚开始是使用string[]数据，而不是使用类或者其它结构来保存，也尝试使用结构提来保存，但是由于四个字段，数据量大，两头还要作为参数传递，所以比使用类还大，这里只是简单的使用了数组。

除了上面这些之外，为了提高搜索效率，对数据按照0-9，a-z开头对数据做了切分分块缓存，这样当用户输入0时，直接从以0为key的块中读取数据，这样速度是加快了，但是大量的缓存也添加了对内存的耗费。缓存的数据基本上和加载到内存中原始的数据一样大了。并且在搜索的过程中，也是采用的完全搜索，对于17万条数据的四个字段，每一次查询要进行170000*4次遍历比较，才能找出最婚配的10条数据来。

为此，引入了不完全搜索，就是事先对各类型证券，如 股票，基金，债券分类，对每一类按证券代码进行排序。当用户设置了搜索的优先级时，顺次在每一类中查找，如果找到满足条件的10条记录，则立即前往，由于数据曾经事先按照证券类型和代码排好序了，所当前面找到的肯定没有之前找到的婚配度高，这一改进直接提高了搜索查询的效率。对有序的数据进行查找效率普通会比无序的数据查找效率高。我们常见的一些查找算法，比如说，二分查找法，前提也是待查找的集合有序陈列。

三、采用非托管代码或者模块编写数据处理逻辑

上面的两部操作虽然减少了将近50-60%的内存占用，但是仍然达不到领导的要求，于是又尝试并比较了各种 使用不同的数据结构将数据载入到内存中的内存占用大小，包括直接将文件按类型读成字符串、数组、结构及类，内存占用最小的直接将文件读成字符串，10M的数据文件读进内存也会占用20-30M的空间，还不谈对其进行处理过程中产生的一些临时变量对内存的占用。使用dotTrace及CLR Profile等工具检查之后，发现内存的占用也是这些原始数据。然后以” How to reduce the memory usage of .NET applications” 到网上搜了一下减少.NET内存占用的一些方法，在StackOverflow上看到了这一回答：

该同学指出.NET使用程序和其他使用本地代码编写的程序相比会有较大的内存占用，如果对内存开销比较在意，.NET可能不是最好的选择。.NET使用程序的内存一定程度上受垃圾回收的影响。并指出，一些数据结构如List，系统会分配多余的空间。可以使用值类型而不是援用类型，不要创建大对象，以免产生内存碎片等等降低内存占用的建议。

这些都考虑过之后，内存还是达不到要求，所以开始寻觅调用非托管代码的方式来本人更灵活的控制内存的分配与销毁。但是整个程序都是采用.NET编写的，全部切换成C或者C++不理想，所以只要两种方案，一是使用unsafe 代码，二是将数据加载和检索模块采用C或者C++编写，在.NET中采用P/Invoke技术调用。

刚开始想采用unsafe代码，对数据的加载及检索直接在放在unsafe 代码中。后来觉得代码有些乱，不同风格的代码混杂在一同不太好，而且数据加载和检索的逻辑也比较复杂。所以就直接采用第二种方案，使用C++编写数据加载和检索逻辑。然后在.NET里面调用。

在开始之前，也做了一些评估，比如将同样的10M的数据加载到内存中，都采用字符串的方式存储，.NET中会占用20-30M的内存，而在C++中只要9-10M的样子，而且变动很小。这正是需求的结果。

由于对C++不熟，临时抱佛脚，翻了下C++ Primier Plus中关于字符串和STL的相关章节，并请求其他开发小组给予了一定的协助，定义了基本的接口。为了演示，我创建了两个工程，一个是名为SecuData的C++