我们经常胡乱对付着解决问题，欣喜于不大不小的成功，接受失败，并且相信下次会更幸运。 

                                                                             ----摩根•琼斯

     

           "使用正则表达式的时候一定不要使用RegexOptions.Compiled选项,不仅不会加速还会让内存飙升; 我们就是这个情况，去掉就好了."这个来自实践而又违反常识的结论让我的朋友很欣喜，显然这个经验要进入他和他团队的知识库了。我写了一个Demo测试了一下，加上RegexOptions.Compiled选项没有带来内存问题,没有印证他所说的结论.

           对于一个问题的梳理我需要从问题上下文开始,而不是一个结论.沟通得知他遇到的情景是这样的:用户提交所有内容要按照有关部门提供的敏感词表使用正则表达式进行敏感词过滤.

          他所处的上下文环境的特点是:

         1.正则表达式构造是依赖于一个敏感词表,而敏感词数量3000左右

         2.他使用正则表达式过程中使用了RegexOptions.Compiled.

        3. 这个正则表达式会被反复使用

    于是我调整了Demo模拟他的环境,敏感词表数据使用GUID代替,代码如下:

    Demo 
     1 Console.WriteLine("---------------------------------------------------");
     2             for (int i = 0; i < 100000; i++)
     3             {
     4                 string temp = "kkkkkksdkfjskldjfskljfklahsjdkfhajksdhfjkahsdfjkhasjkdfhjkahdfjkahsdfjkh";
     5                 string Filtered = Guid.NewGuid().ToString();
     6                 Regex mRegex = new Regex(Filtered, RegexOptions.IgnoreCase | RegexOptions.Compiled);
     7                 if (mRegex.IsMatch(temp))
     8                 {
     9                   //Do nothing
    10                  }  
    11             }
    12 
    13             Console.WriteLine("---------------------------------------------------");
    14  

     


    这下真的内存飙升了…

    RegexOptions.Compiled真的是性能杀手么?

    关于这个问题,BCL团队已经在其团队博客上给出了详细的解释(点击这里查看),文中从初始化性能和运行时性能考查了三种使用正则表达式的方式;结果归纳如下:

     

     

     

    导致内存飙升的就是下面这个原因:

    Emitting IL with Reflection.Emit loads a lot of code and uses a lot of memory, and that's not memory that you'll ever get back.  In addition. in v1.0 and v1.1, we couldn't ever free the IL we generated, meaning you leaked memory by using this mode.  We've fixed that problem in Whidbey. 


    虽然现在实现了内存释放    ,但是这种使用方式占用内存还是显而易见的.所以他们建议:

    But the bottom line is that you should only use this mode for a finite set of expressions which you know will be used repeatedly. 

    1.表达式是一个有限集合 2.表达式集合会被反复使用 

     

    对于朋友的情况,这个过滤相关的表达式肯定是符合这两条的,所以应该使用Compiled的方式,但是考虑到第二种方式对内存的影响以及初始化占用较长时间,所以对他来说最佳选择是使用第三种编译到程序集的方式.关于第三种方式的实现请移步查看这篇文章:"To Compile or Not To Compile"

     

    -----------------关于这个问题我想说的是----------------------

     

            这位朋友的真实情况是他没有在当前的上下文环境中采取正确的使用方式,而他对这个问题的解决仅仅是回退到一个性能较差只不过没有"内存飙升"的方案上,同时对RegexOptions.Compiled下了一个性能差的结论.


    去年我在的一件小事:

           数据库服务器异常缓慢,翻了翻日志,我猜测问题可能出现在什么地方,然后修改了程序集做更新,更新期间重启了一下SQL Server服务;然后宣布这个问题解决了;这期间于老师一直通过SQL Server Performance Monitor观察;过了没有多久,于老师指出真正的问题在于有一个存储过程的语句锁表造成了阻塞和更新的程序集没有任何关系;而之所以更新了程序集就见效了是因为更新过程中误打误撞重启了SQL Server,不修改存储过程问题依然存在;果然一段时间后数据库又开始慢了…

         那一次,于老师很不高兴,并不是因为那个问题的影响有多大,而是这个问题的解决过程:

  1. 解决问题的过程往往是从"猜"开始,"猜"就是给出解决方案到现象的因果关系;而我只是猜测可能出现在什么地方,但是没有思考为什么是这里,缺少理由
  2. 真正让于老师恼火的在于"大家竟然也就接受了我的解决方案",没有其它人对这个问题进行思考,对这个方案提出质疑

    也就是从这件事情开始    ,对于一个问题我总是会问自己下面的问题: 
    1. 要解决的问题到底是什么,或者说我们怎么定义这个问题?
    2. 我们对这个问题已经了解到什么程度?我是否可以对这个问题进行重述?
    3. 这个问题我们已经解决到了什么程度?我们是不是已经偏离了正确的方向?
    4. 我们采取了什么措施使得问题解决了?
    5. 我们的采取的措施真的就是这个问题的解决方案么?它们存在因果关系么?它为什么有效?
    6. 我们采取的措施是否真正解决了问题?是否带来了新的问题?

    4.  

    这几个问题,让我少了很多浮躁,多了一些质疑,而且动手验证了很多是是而非的"经验",这个过程让我受益匪浅;


     

    PS:网上有很多针对SQL Server的SQL语句优化经验,那么这些经验为什么有效?在SQL Server2008中,它们依然有效么?