由Log4r的性能有关问题，思维稍稍发散了一上
由Log4r的性能问题，思维稍稍发散了一下
一个月前做了一个Ruby的开源项目，用来做性能测试用的，功能是提供一个性能测试的环境，做好了写日志、存储结果、数据计算分析等方法，使用者只要用Ruby写个代码块，然后丢给这个环境的一个方法去反复迭代执行，就完成了压力的生成，这是最简单的模型。
这个版本目前已经到了3.1了，之前我用的还不错，后来发现，随着代码不断的改动，功能不断的丰富，这个环境（我就先叫这个项目为环境吧，叫XXXX框架什么的太装B了）执行迭代的速度越来越慢，抽了个空，又回头看了下我写的代码，终于发现了大部分的问题所在。
在负责迭代执行的一个方法内，有一条代码负责记录该次执行时的日志。我们都知道，日志是分级别的，当前环境变量中设定的级别要是高于代码中要显示日志的级别时，该条日志将不输出。我写代码的时候以为它不输出就不会消耗太多性能，结果注释掉这些日志方法后，发现这个环境的迭代执行效率提高了4倍！
请看下面这个代码：
为啥呢？
我认为是：即便当前环境设定输出的日志级别是：Error或者更高，但是解释器执行到这段代码是肯定有个判断的过程，先得到环境设定好的日志级别和该代码的级别，然后做个判断，再决定是否写入。就是这个判断，消耗了太多的性能。
平时这个东东用在普通的项目里（rails，sinatra等），不太会发现有什么大问题，往往别的问题性能比较严重。但我把它用在一个压力生成的环境中，每次运行都会跑上千上万次，于是性能问题就凸现出来了。
像这种问题，如果不亲身经历，估计不太会被关注，趁着年轻，多多积累经验吧。
一个月前做了一个Ruby的开源项目，用来做性能测试用的，功能是提供一个性能测试的环境，做好了写日志、存储结果、数据计算分析等方法，使用者只要用Ruby写个代码块，然后丢给这个环境的一个方法去反复迭代执行，就完成了压力的生成，这是最简单的模型。
这个版本目前已经到了3.1了，之前我用的还不错，后来发现，随着代码不断的改动，功能不断的丰富，这个环境（我就先叫这个项目为环境吧，叫XXXX框架什么的太装B了）执行迭代的速度越来越慢，抽了个空，又回头看了下我写的代码，终于发现了大部分的问题所在。
在负责迭代执行的一个方法内，有一条代码负责记录该次执行时的日志。我们都知道，日志是分级别的，当前环境变量中设定的级别要是高于代码中要显示日志的级别时，该条日志将不输出。我写代码的时候以为它不输出就不会消耗太多性能，结果注释掉这些日志方法后，发现这个环境的迭代执行效率提高了4倍！
请看下面这个代码：
self.log.debug "IterationID is #{self.iterationId};UserID is #{self.userId};This Action Cost #{rcost} seconds"
为啥呢？
我认为是：即便当前环境设定输出的日志级别是：Error或者更高，但是解释器执行到这段代码是肯定有个判断的过程，先得到环境设定好的日志级别和该代码的级别，然后做个判断，再决定是否写入。就是这个判断，消耗了太多的性能。
平时这个东东用在普通的项目里（rails，sinatra等），不太会发现有什么大问题，往往别的问题性能比较严重。但我把它用在一个压力生成的环境中，每次运行都会跑上千上万次，于是性能问题就凸现出来了。
像这种问题，如果不亲身经历，估计不太会被关注，趁着年轻，多多积累经验吧。