Lucene分词组件盘古与mmseg4j评测
前言
.Net 下分词组件选择不多，最近看到宝玉发布了改进版本的mmseg分词，正好跟使用已久的盘古分词做个对比。
盘古是用自动机来实现分词，更详细的分析http://www.cnblogs.com/eaglet/archive/2008/10/02/1303142.html
mmseg的算法相对先进一些，更详细的解释：http://www.coreseek.cn/opensource/mmseg/
这里只对比盘古默认的配置，因为默认中不打开一元分词已经满足需求，mmseg只对比maxword的配置，目标是多元分词的效率和效果。
效率对比
硬件配置：CPU i7 2.3GHz RAM 4GB
盘古分词
官方效率：Core Duo 1.8 GHz 下单线程 分词速度为 390K 字符每秒，2线程分词速度为 690K 字符每秒。
默认配置单线程：395kw/s，比官方要慢一些因为硬件配置比官方高，但相差不多。
默认配置多线程：744.7，也跟官方差不多；
mmseg分词
官方效率（java）：
- 1.5版的分词速度simple算法是 1100kb/s左右、complex算法是 700kb/s左右，（测试机：AMD athlon 64 2800+ 1G内存 xp）。
- 1.6版在complex基础上实现了最多分词(max-word)。“很好听” -> "很好|好听"; “中华人民共和国” -> "中华|华人|共和|国"; “中国人民银行” -> "中国|人民|银行"。
- 1.7-beta 版, 目前 complex 1200kb/s左右, simple 1900kb/s左右, 但内存开销了50M左右. 上几个版都是在10M左右.
- 1.8 后,增加 CutLetterDigitFilter过虑器，切分“字母和数”混在一起的过虑器。比如：mb991ch 切为 "mb 991 ch"。
MaxWord方式单线程：比盘古慢很多，可能跟mmseg算法比较复杂有关，每个chunk都要计算四个因子。
MaxWord方式多线程：没有提升很多，这也说明了mmseg的瓶颈实在计算上。
实例分析对比
实例一
原文
【用数据告诉你手游有多热】今天，作为本届GMIC 的一部分，GGS全球移动游戏峰会召开。嘉宾和游戏开发者们探讨了移动游戏的现状与发展趋势。手游则是最为重要的一大关键词。盛大游戏总裁钱东海分享了日本最大手游公司CEO预测的数据：2015年全球游戏产业的格局中80%都是手机游戏。http://t.cn/zTHdkFY
盘古
用/数据/告诉/你/手游有多热/今天/作为/本届/GMIC/的/一部分/GGS/全球/移动/游戏/峰会/召开/嘉宾/和/游戏/开发者/们/探讨/了/移动/游戏/的/现状/与/发展趋势/手游则是/最为/重要/的/一/大/关键词/盛大/游戏/总裁/钱/东海/分享/了/日本/最大/手/游/公司/CEO/预测/的/数据/2015/年/全球/游戏/产业/的/格局/中/80/都是/手机/游戏/http/t/cn/zTHdkFY
mmseg
用/数据/告诉/你手/游/有多/热/今天/作为/本届/gmic/的/一部/部分/ggs/全球/移动/游戏/峰会/召开/嘉宾/和/游戏/开发/者/们/探讨/了/移动/游戏/的/现状/与/发展/趋势/手/游/则是/最为/重要/要的/一大/关键/词/盛大/游戏/总裁/钱/东海/分享/了/日本/最大/手/游/公司/ceo/预测/的/数据/2015/年/全球/游戏/产业/的/格局/中/80/都是/手机/游戏/http/t/cn/zthdkfy
评测
盘古的分词要理想一些，mmseg的“你手”分词不理想；
实例二
原文
前几天看到一篇文章里提到过，在批量插入时，需要加上Context.Configuration.AutoDetectChangesEnabled = false;
文章原话：EF默认会自动的跟踪数据的变化，当变更的数据量较大的时候，EF的跟踪工作量就会骤增，但指定操作变得非常缓慢（这也是部分同学怀疑EF的性能问题的一个怀疑点），其实，只要在批量操作的时候把自动更新关闭，即可解决缓慢的问题。
大家自己去看看：http://www.cnblogs.com/guomingfeng/archive/2013/05/28/mvc-ef-repository.html由于没测试，所以不知道结果是不是变快，快多少
结果早上发现首页一个测试Entity Framework的文章，http://www.cnblogs.com/newton/archive/2013/06/06/3120497.html 说EF性能不行，正好没加这句，我也好奇，所以自己测试下，写这个文章不是针对作者，只是自己好奇，互相讨论
盘古
前几天/看到/一篇/文章/里/提到/过/在/批量/插/入时/需要/加上/Context/Configuration/AutoDetectChangesEnabled/=/false/文章/原话/EF/默认/会/自动/的/跟踪/数据/的/变化/当/变更/的/数据量/较大/的/时候/EF/的/跟踪/工作量/就/会/骤增/但/指定/操作/变得/非常/缓慢/这/也是/部分/同学/怀疑/EF/的/性能/问题/的/一个/怀疑/点/）/其实/只要/在/批量/操作/的/时候/把/自动更新/关闭/即可/解决/缓慢/的/问题/大家/自己/去/看看/http/www/cnblogs/com/guomingfeng/archive/2013/05/28/mvc/ef/repository/html/由于/没/测试/所以/不/知道/结果/是不是/变/快/快/多少/结果/早上/发现/首页/一个/测试/Entity/Framework/的/文章/http/www/cnblogs/com/newton/archive/2013/06/06/3120497./html/说/EF/性能/不行/正好/没加这句/我/也/好奇/所以/自己/测试/下/写/这个/文章/不是/针对/作者/只是/自己/好奇/互相/讨论
mmseg
前/几天/看到/一篇/文章/里/提到/过/在/批量/插入/时/需要/加上/context/configuration/autodetectchangesenabled/false/文章/原话/ef/默认/会/自动/的/跟踪/数据/的/变化/当/变更/的/数据/量/较大/的/时候/ef/的/跟踪/工作/量/就会/骤增/但/指定/操作/变得/非常/缓慢/这也/是/部分/同学/怀疑/ef/的/性能/问题/的/一个/怀疑/点/其实/只要/在/批量/操作/的/时候/把/自动/更新/关闭/即可/解决/缓慢/的/问题/大家/自己/去看/看/http/www/cnblogs/com/guomingfeng/archive/2013/05/28/mvc/ef/repository/html/由于/没/测试/所以/不知/知道/结果/果是/不是/变/快/快/多少/结果/早上/发现/首页/一个/测试/entity/framework/的/文章/http/www/cnblogs/com/newton/archive/2013/06/06/3120497/html/说/ef/性能/不行/正好/没/加/这句/我也/好奇/所以/自己/测试/下/写/这个/文章/不是/针对/作者/只是/自己/好奇/互相/讨论
评测
mmseg的分词要细一些，对“前几天”和“不知道结果是不是变快很多”的分词都优于盘古。
总结
最后的分词评测的用例还是不多，更多的用例可以下载下面的源码后自行测试。分词器上盘古的功能更完整丰富，mmseg更多的是算法上的实现，但是功能匮乏。