Rails应用优化指南 (2)

优化ActionController

　　使用components会对ActionController的性能造成较大的影响，我的建议是没有特别的理由，不要使用components，因为调用render_component会引发一个新的请求处理循环。大部分情况下，component都可以使用helper 或者partials代替。

　　优化ActionView

　　对于每一个请求，Rails都会创建一个controller和view实例，并会将controller的action中创建的实例变量通过 instance_variable_get和instance_variable_set传递给view，因此不要在action中创建view中用不到的实例变量。

　　优化helper

　　首先是pluralize，可以看一下pluralize的实现，如果不给出最后一个参数，它会创建一个Inflector实例，因此不要写pluralize(n, ‘post’)，应该写成pluralize(n, ‘post’, ‘posts’)。

　　其次是link_to与url_for，由于需要查找路由策略，因此link_to与url_for可以说是最慢的helper方法，没有特别的需要，不要使用这两个函数。

＜a href=“/recipe/edit/＜%=#{recipe.id}%＞”class=“edit_link”＞
look here for something interesting
＜/a＞

　　会比下面这段同样结果的代码快许多：

＜%= link to “look here for something interesting” ,{ :controller =＞ “recipe”, :action =＞ edit, :id =＞ @recipe.id },{ :class =＞ “ edit link” } %＞。


　　优化ActiveRecord

　　访问AR对象的关联对象相对而言会比较慢，可以使用:include提前获取关联对象

class Article
belongs to :author
end
article.find ( :all, :include =＞ :author)


　　或者使用piggy backing指定要获取的关联对象的某些字段，关于piggy backing的介绍请参看[2]

class Article
piggy back :author name, :from =＞ :author, :attributes =＞ [:name]
end
article = Article . find ( :all, :piggy =＞ :author)
puts article .author name


　　另外需要注意的是，从数据库中获取的字段值一般来说都是String类型，因此每次访问可能都需要进行类型转换，如果你在一个请求处理过程中需要进行多次转换，那么最好对转换后的值进行缓存。

　　还有，根据我对一个应用的分析，大约有30%的时间花在了字符处理上，另外30%时间花在了垃圾收集，还有10%用于URL识别，因此在数据库中缓存格式化后的字段可以大大减小字符处理的开销。

　　优化Ruby代码

　　前面，我们的优化策略主要是针对Rails框架本身进行，现在我们将精力集中到Ruby语言本身上来。

　　首先，Ruby语言中的各种元素由于算法的不同，访问时间也各不相等，比如局部变量采用数组索引，在解析时进行顶问，因此访问代价总是O(1)，而实例变量和和方法调用由于使用Hash访问，因此只能保持理论上的O(1)访问，也就是没有冲突的情况下，同时调用方法时如果不能在子类找到这个方法，则还需要沿继承树向上回溯查找。

　　因此，应该尽量避免不必要的多态继承，同时应该尽量使用局部变量，比如下面这段代码的效率就不如修改后的高：

def submit to remote(name, value, options = {})
options[ :with ] ||= ’Form.serialize( this .form)’
options[:html ] ||= {}
options[:html ][ :type ] = ’button’
options[:html ][ :onclick ] = ”#{remote function(options)}; return false ; ”
options[:html ][ :name] = name
options[:html ][ :value] = value
tag(”input” , options[:html ], false )
end


　　修改后：

def submit to remote(name, value, options = {})
options[ :with ] ||= ’Form.serialize( this .form)’
html = (options[:html ] ||= {})
html[:type ] = ’button’
html[:onclick ] = ”#{remote function(options)}; return false ; ”
html[:name] = name
html[:value] = value
tag(”input” , html, false )
end


　　其次，对于经常用到的数据，应该进行缓存，避免每次用到时再进行计算，比如：

def capital_letters
( ”A” .. ”Z” ). to a
end


　　写成下面这样会更好：

def capital letters
　@capital letters ||= ( “A” .. “Z” ). to a
end



　　当然对于上面这种情况，如果所有类需要的数据都相同，那么完全可以将它定义成class级变量：

@@capital letters = (“A” .. “Z” ). to a
def capital letters
@@capital letters
end


　　当然，除了效率也要注意优美，下面这段代码就不够优美：

def actions
　unless @actions
　# do something complicated and costly to determine action’s value
@actions = expr
end
@actions
end



　　改成这样会更好一些：

def actions
@actions ||=
begin
# do something complicated and costly to determine action’s value
expr
end
end


　　另外，使用常量对效率也有一定提升。

def validate_find_options (options)
options.assert valid keys( :conditions , :include , :joins , :limit , :offset ,
:order , :select , :readonly, :group, :from )
end



　　上面这段代码进行如下修改会更好一些:

VALID FIND OPTIONS = [
:conditions , :include , :joins ,:limit ,:offset ,:order , :select ,:readonly,:group,:from ]
def validate find options (options)
options.assert valid keys(VALID FIND OPTIONS)
end



　　同时，应该尽可能的使用局部变量。

sql ＜＜ ” GROUP BY #{options[:group]} ” if options[:group]


　　上面这种方式明显不如以下两种：

if opts = options[:group]
sql ＜＜ ” GROUP BY #{opts} ”
end
opts = options[:group] and sql ＜＜ ” GROUP BY #{opts} ”



　　当然，能够写成这样是最好的：

sql ＜＜ ” GROUP BY #{opts} ” if opts = options[:group]


　　但是目前版本的Ruby还不支持这样做。

　　另外，还有一些小技巧：

logger.debug ”args: #{hash.keys.sort.join ( ’ ’ )}” if logger


　　这段代码的问题在于，不管logger.level是否为DEBUG，hash.keys.sort.join(’ ’) 都会被执行，因此，应该写成这样:

logger.debug ”args: #{hash.keys.sort.join ( ’ ’ )}” if logger && logger.debug?


　　还有就是关于ObjectSpace.each_object的，在production模式最好不要使用这个方法。

ObjectSpace.each object(Class) {|c| f(c) }


　　事实上这跟下面的代码是相等的：

ObjectSpace.each object {|o| o.is a?(Class) && f(o) }


　　它会对堆上的每一个对象都进行检查，这会对性能造成极大损耗。