最近写了个小程序，合并两本英语词典的例句。算法很简单，就是用个键值对的数据结构来保存词条，词作为键，例句作为值，如果键已存在，就将例句加在已有例句的末尾。最后输出全部键值对到文本文件。因为还要用MdxBuilder将文本文件转成mdict格式的词典，转换过程中是会重新排序的，所以输出到文本文件时，不必考虑排序，比如-able可以出现在最前面，也可以出现在abide后面，无关紧要。

用什么数据结构呢？可供选择的主要有Dictionary，SortedList，SortedDictionary。当然还有其他一些类似的类可用，但觉得我这个需求并不特殊，没必要用第三方为了特殊目的开发的库，所以就在.net framework提供的这三个类里选择了。Hashtable太老，不支持泛型，用起来太麻烦，就不考虑了。至于Dictionary的其他变体，如ConcurrentDictionary等，也不考虑。

说实话以前对它们的区别没什么研究，查了下，结论很简单易懂，但必须通过实践来检验。

测试结果，Dictonary最快，134551毫秒，SortedList其次，135995毫秒，SortedDictionary最慢，136070毫秒。（简单地用StopWatch，不在意那么精确）

这里不想讨论为什么有这个差距，因为随便查一下就能找到三个类的区别，不用我多费口舌。

总共处理了大约30万词条，耗时约2分钟（2009年的老机器，耗时包括每隔200词条显示一次进度的开销），相对这个耗时来说，不到2秒钟的差距可以说没什么大碍。也就是说，只有处理相当大的数据，比如300万，才可能在用户体验上有显著的差异。

所以我想说的是，网上有不少比较不同类的性能差异的帖子。了解一点是好的，但是关键在于具体的应用。一般来说，只有相当大的数据规模时，这种性能差异才比较显著。不太大的数据规模，差异不大，不必过于纠结用那个。所以平时不必过于热衷这类帖子，也不必将掌握此类性能差异的知识当作所谓“基本功扎实”。只要意识到类似功能的类可能会有性能差异，具体选用哪个，碰到具体的需求时再查下资料也不迟。这不应作为优先考虑的学习目标。至于为了应付求职面试，那是另外一回事。但是我想多数单位，其实也不见得每天要处理海量数据，很多此类的面试问题其实没什么应用价值。

更重要的是算法。比如上面这个例子，将每隔200词条显示一次进度改成每隔400显示一次，即使用SortedDictionary也只要86982毫秒，足足快了近50秒。可见，在这个问题上，瓶颈在于ui，而将SortedDictionary换成Dictionary，对性能并没有决定性的影响。

所以在处理性能问题上，首先要考虑瓶颈在哪里，而瓶颈，一般不会在这种类和数据结构的差别上。