- 解决问题的过程往往是从"猜"开始,"猜"就是给出解决方案到现
象的因果关系 ;而我只是猜测可能出现在什么地方,但是没有思考为什么是这里 ,缺少理由 - 真正让于老师恼火的在于"大家竟然也就接受了我的解决方案",没
有其它人对这个问题进行思考 ,对这个方案提出质疑
也就是从这件事情开始,对于一个问题我总是会问自己下面的问题: - 要解决的问题到底是什么,或者说我们怎么定义这个问题?
- 我们对这个问题已经了解到什么程度?我是否可以对这个问题进行重
述 ? - 这个问题我们已经解决到了什么程度?我们是不是已经偏离了正确的
方向 ? - 我们采取了什么措施使得问题解决了?
- 我们的采取的措施真的就是这个问题的解决方案么?它们存在因果关
系么 ?它为什么有效? - 我们采取的措施是否真正解决了问题?是否带来了新的问题?
我们经常胡乱对付着解决问题,欣喜于不大不小的成功,接受失败,
"使用正则表达式的时候一定不要使用RegexOptions.
对于一个问题的梳理我需要从问题上下文开始,而不是一个结论.沟
他所处的上下文环境的特点是:
1.正则表达式构造是依赖于一个敏感词表,而敏感词数量3000
2.他使用正则表达式过程中使用了RegexOptions.
3. 这个正则表达式会被反复使用
于是我调整了Demo模拟他的环境,敏感词表数据使用GUID代
![](https://images.cnblogs.com/OutliningIndicators/ExpandedBlockStart.gif)
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团队已经在其团队博客上给出了详细的解释(
![](https://images.cnblogs.com/cnblogs_com/me-sa/99450/r_regex.png)
导致内存飙升的就是下面这个原因:
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.表达式集合会被反复使用
对于朋友的情况,这个过滤相关的表达式肯定是符合这两条的,所以
-----------------关于这个问题我想说的是-------
这位朋友的真实情况是他没有在当前的上下文环境中采取正确的使用
去年我在的一件小事:
数据库服务器异常缓慢,翻了翻日志,我猜测问题可能出现在什么地
那一次,于老师很不高兴,并不是因为那个问题的影响有多大,而是
这几个问题,让我少了很多浮躁,多了一些质疑,而且动手验证了很
PS:网上有很多针对SQL Server的SQL语句优化经验,那么这些经验为什么有效?在