标签：词条 例句 性能 小心 SortedDictionary 毫秒 关于 差异

最近写了个小程序，合并两本英语词典的例句。算法很简单，就是用个键值对的数据结构来保存词条，词作为键，例句作为值，如果键已存在，就将例句加在已有例句的末尾。最后输出全部键值对到文本文件。因为还要用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，对性能并没有决定性的影响。

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

标签：词条,例句,性能,小心,SortedDictionary,毫秒,关于,差异
来源： https://www.cnblogs.com/badnumber/p/15978860.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。