摘要:昨天和今天，我都在对我之前写的UBB解析代码进行性能优化。优化的结果是：1个具有600多个UBB标签的文本，包含多层UBB嵌套，优化前，解析出这个文本需要2分钟，优化后解析出这个文本需要1秒钟。而这次优化，核心优化的技术只有一点：正则表达式Regex 的构造位置发生变化。下面我就来慢慢来说这次优化。 UBB解析组件的简单介绍 需求： 1、把支持的14个UBB标签解析成不同的Html文本。这14个标签包含：代码高亮标签、禁用UBB标签以及一些通用的UBB标签。 2、一部分UBB 标签支持嵌套的解析，比如对以下文本的解析： [b]1[i]2[/i]3[/b] ，要求2这个文本，需要解析成加粗同时是斜体； 3、一部分UBB标签不支持嵌套的解析，比如：代码高亮的UBB标签括的范围内，任何UBB标签都不起作用。 当然，还有很多其他需求限制，这里只罗列影响我UBB解析算法的一些重要需求。我写的这个UBB代码解析的规范，可以参看以下链接：http://forum.csdn.net/help/ubb.html 我的设计： 先把一段包含UBB标签的文本解析成一个树，树的每一个末梢节点都是不能再继续拆分下去的一段文本，即：其下没有起作用的嵌套UBB标签。然后把这个树的每个节点解析内容合并成一段新的文本。 这个算法的瓶颈在把文本解析成树，解析成树后的计算，系统消耗很少，可以忽略不计。 解析成树的算法，我的设计如下： 先在这个文本中，使用正则表达式从头开始找起，找到第一个系统支持的UBB标签，比如我们找到了一个[b] 文本。然后从找到位置开始，向后，找 [/b] 文本，这两个寻找都是使用的正则来寻找，根据这两个寻找的三种结果，分别进行处理． 然后再用递归算法，不停的循环上述处理逻辑，从而把文本解析成树。 我的代码优化 优化前性能不高的代码： // 在一段文本中，从指定位置开始，找到系统支持的UBB标签文本，比如之前的例子，找 [b] [i] 这些文本 private bool MatchBeginTag(int beginPos, out UBBCodeFragmentType ubbType, out string ubbParameterValue, out int tagPrePos, out int tagEndPos) { ...... Regex rx_MatchBeginTag = new Regex(@"\[(?<tagName>[a-zA-Z]+)(=(?<value>[^\f\n\r\t\v\]]*))?\]", RegexOptions.Compiled | RegexOptions.IgnoreCase); ......} // 从指定位置开始，向后 找指定标签的结束标签 private bool MatchEndTag(int beginPos, string tagName, out int tagPrePos, out int tagEndPos) { ...... Regex rx_MatchEndTag = new Regex(@"\[/" + tagName + @"\]", RegexOptions.Compiled | RegexOptions.IgnoreCase); ......} 上述两个函数分别实现之前说的两个功能，这两个函数会被频繁的递归调用，比如我之前说的场景，600多个UBB标签的文本，这两个函数会被600次的调用到。 我的优化方法 我通过使用 JetBrains dotTrace 3.0 工具，看到 Regex 的构造函数被频繁的调用，累计调用花费的时间非常巨大，我在这里对它进行代码调整． 对于 MatchBeginTag 函数， 由于它用的 Regex rx_MatchBeginTag 是固定的，很简单，我把这个对象放在函数体之外，把它定义成静态成员，这样它只需要构造一次，改造成如下代码方式： private......[
阅读全文]