Dictionary<string, string> fixKeys = new Dictionary<string, string>(StringComparer.InvariantCultureIgnoreCase);
            foreach (string key in scanKeys)
            {
                fixKeys[key] = key;
            }
            scanKeys = new string[fixKeys.Count];
            fixKeys.Values.CopyTo(scanKeys, 0);
            return scanKeys;

注意：上面的代码是假设你的算法能够忽略待检文本的大小写问题的。
有人就这么问我：为啥我用了一个很好的算法，最后效果还是有点不理想呢？我想这是一个可能的原因。通常我们所说的算法，都是讨论一些核心的问题。而类似这种问题，通常不会在WM/grep等算法的论文里面讨论。因为无论我们使用哪一种算法，这一个排重的步骤都是一样的，你可以认为是必须的，或者是不必要的。但是如果你真的希望提高效率，这也是一个值得你关注的地方。或者说，你得考虑一下当开始做最核心的事情之前，你是否已经将准备工作做得充分了。

从这个方向引申开来，还有一个可以优化的地方，就是是否考虑把脏字表转换成最小集合？比如这么说，当XYZ和Y都是原始脏字表条目的时候，你是否打算去掉XYZ呢？这个取决于你的任务。如果你的任务是，看看某篇文章是否有敏感词汇，如果有，就转人工检查。这个时候只要有最小集合就足够了，不需要最大匹配。但是如果你的任务是，只要是脏字，都需要用星星覆盖，不但不应该转换为最小集，反而应该增强你的算法（即使是牺牲性能）。记得有本书就说过，不要无的放矢。首先要知道目标在那里，才好射到靶上，射到靶上了，我们再来讨论如何给射准。通常我们看一段代码他是否能瞄准其目的，也可以判断出开发者在某些方面的水平如何。而我的任务目标是前者，于是乎就不需要作这个缩小最小集的工作了。顺便提醒一下，如果是后一种任务，普通算法是会有缺陷的，例如：
脏字表：
XYZ
X
待检文本：
WXYZA
被屏蔽之后会变成：
W*YZA
而不是我们所期望的：
W***A
这样的结果有可能是不理想的，因为这样可能还是有一些不雅的内容会被读出来。
这个时候即使检索出X，也不能够退出循环，需要继续检索更长的文本。这个过程也许是可以优化的，但无论如何都是要比原来多消耗一定的性能的。

当然了，如果说要做到极致，我可以用这么一段程序把原始脏字表给整理一下，缩小成最小集，然后生成修正后的脏字表文件供核心算法使用。而我目前并没有选择这么做，一个是觉得开发这么一个程序花的时间不见的能节省可观的时间。另一个问题是，有可能未来任务会转换为后者时，这个时候就不应该用最小集，原来做的这个工作可能就白费了。

下一个性能损耗点是在读取待检文本的时候，这个在什么位置呢？如果看过操作系统设计的相关书籍，我们应该知道，当我们进行磁盘操作的时候，CPU会是空闲的。我们的待检文本，不是储存于数据库中，就是储存于一个个单独的文件里面。无论是哪一种情况，我们都可能存在CPU等IO的情况。除此之外，通常一台服务器上面可能会有不止一个CPU，一个CPU也可能有不止一个内核。因此为了提高整体的检索性能，使用多个线程也是另一个必要的手段。关于这个话题，相信网上也会有很多的文章会讨论到，至少是类似的问题，这里就不再熬述了。如果你打算通过多线程进一步提高效率，我可以提醒大家的一点是，不可把性能压榨到极致，否则可能会影响到普通用户的使用。另一个需要注意的问题是，无论你是否打算用多线程，都要注意同一个时刻应该只允许有唯一一个进程在处理。如果是多个进程同时在做这样的检查，就很有可能都在检同一篇文章，这样无谓的性能损失是，无论算法再快也挽救不了的。可行的方法有很多，比如说把这个东西做成一个服务，永远就只有一个进程在做，同时内部有一个同步锁，不允许重入。又或者有一个数据库级别的锁，锁上了就不让其他人通过页面去启动这样一个检索过程。

有没有必要弄个分布式呢？一般来说，我们不是做搜索引擎，自有数据量还是比较有限的。能有一台服务器单独作这么一个工作，我估计就已经很了不起了。通过上面的多线程来压榨服务器性能，通常已经足够了。分布式处理可能会让你面临不小的技术难点，开发调试过程也比较麻烦。我建议这个作为最后的手段，在这之前还不如考虑配置一台有更多更快速CPU的服务器，或者考虑简单的空间换时间手段。其实我个人觉得，很难想象用户上传文字的速度，会超过一台服务器的处理速度。如果到了这样的一种程度，估计首先需要分布式处理的不是这个脏字过滤程序了，而是你的站点象用户提供服务的程序了。

上面说的这些，你说是算法吧，严格说来也不是，不过确实也是一段代码，也是一种解决问题的思路，这就是我标题里面“算法前传”的意思了。剩下来的，就是检索过程了。这一个前传就到此为止，希望能给大家另外一个提高效率的思路，同时也为达到你的算法的最高效率做好必要的准备。下一篇会先拆解一下TTMP-F和TTMP-B两种模式的概念、优缺点以及实施概略，详细地代码实战，还要酝酿一下。