最近遇到一个eager_load的问题，就搜索了相关的文章，又看了一些Autoload的源代码，感觉不错，分享下。以下内容多数引自原文，并加上部分补充，本人不准备在这里做翻译工作。
或许eager_load_paths是比autoload_paths更好的选择
在Rails的官方文档中提到，可以使用config.autoload_paths += %W(#{config.root}/extras)的方式加载目录。这种加载方式看上去十分美好，不过有一些小小的瑕疵。
Let’s say we have two files
# root/extras/foo.rb
class Foo
end
and
# root/app/models/blog.rb
class Blog < ActiveRecord::Base
end
Our configuration looks like this:
# root/config/application.rb
config.autoload_paths += %W( #{config.root}/extras )
Things are ok in development.Now, let’s check how it behaves in development.
defined?(Blog)
# => nil
defined?(Foo)
# => nil
Blog
# => Blog (call 'Blog.connection' to establish a connection)
Foo
# => Foo
defined?(Blog)
# => "constant"
defined?(Foo)
# => "constant"
As you can see from this trivial example, at first nothing is loaded. Neither Blog, nor Foo is known. When we try to use them, rails autoloading jumps in. const_missing is handled, it looks for the classes in proper directories based on the convention and bang. app/models/blog.rb is loaded, Blog class is now known under Blog constant. Same goes for extras/foo.rb and Foo class.
即在开发环境下，Rails会延迟加载。首先Rails在启动时会记下加载路径，当有找到未定义的constant时，会触发ActiveSupport的const_missing，然后在const_missing中加载constant。
But on the production, the situation is a little different…
defined?(Blog)
# => "constant"
defined?(Foo)
# => nil
Blog
# => Blog (call 'Blog.connection' to establish a connection)
Foo
# => Foo
defined?(Blog)
# => "constant"
defined?(Foo)
# => "constant"
Why is that a problem? For the opposite reasons why eager loading is a good thing. When Foo is not eager loaded it means that:
- when there is HTTP request hitting your app which needs to know about Foo to get finished, it will be served a bit slower. Not much for a one class, but still. Slower. It needs to find foo.rb in the directoriess and load this class.
- All workers can’t share in memory the code where Foo is defined. The copy-on-write optimization won’t be used here.
If all that was for one class, that wouldn’t be much problem. But with some legacy rails applications I’ve seen them adding lot more directories to config.autoload_paths. And not a single class from those directories is eager loaded on production. That can hurt the performance of few initial requests after deploy that will need to dynamicaly load some of these classes. This can be especially painful when you practice continuous deployment. We don’t want our customers to be affected by our deploys.
How can we fix it?
There is another, less known rails configuration called config.eager_load_paths that we can use to achieve our goals.
config.eager_load_paths += %W( #{config.root}/extras )
How will that work on production? Let’s see.
defined?(Blog)
# => "constant"
defined?(Foo)
# => "constant"
Not only is our class/constant Foo from extras/foo.rb autoloaded now, but it is also eager loaded in production mode. That fixed the problem.
简单的做法就是用eager_load_paths代替autoload_paths。Rails是如何控制Development和Production环境下用不同的加载方式的呢？在配置环境里config.eager_load = false可以修改eager_load，Development是false，Production是true。
Autoloading is using eager loading paths as well
def _all_autoload_paths
@_all_autoload_paths ||= (
config.autoload_paths +
config.eager_load_paths +
config.autoload_once_paths
).uniq
end
Unfortunately I’ve seen many people doing things like
config.autoload_paths += %W( #{config.root}/app/services )
config.autoload_paths += %W( #{config.root}/app/presenters )
It is completely unnecessary because app/* is already added there.
You can see the default rails 4.1.7 paths configuration
def paths
@paths ||= begin
paths = Rails::Paths::Root.new(@root)
paths.add "app", eager_load: true, glob: "*"
paths.add "app/assets", glob: "*"
paths.add "app/controllers", eager_load: true
paths.add "app/helpers", eager_load: true
paths.add "app/models", eager_load: true
paths.add "app/mailers", eager_load: true
paths.add "app/views"
paths.add "app/controllers/concerns", eager_load: true
paths.add "app/models/concerns", eager_load: true
paths.add "lib", load_path: true
paths.add "lib/assets", glob: "*"
paths.add "lib/tasks", glob: "**/*.rake"
paths.add "config"
paths.add "config/environments", glob: "#{Rails.env}.rb"
paths.add "config/initializers", glob: "**/*.rb"
paths.add "config/locales", glob: "*.{rb,yml}"
paths.add "config/routes.rb"
paths.add "db"
paths.add "db/migrate"
paths.add "db/seeds.rb"
paths.add "vendor", load_path: true
paths.add "vendor/assets", glob: "*"
paths
end
end
Autoload
在Rails中有很多类似这样的代码：
module ActiveSupport
extend ActiveSupport::Autoload
autoload :Concern
autoload :Dependencies
autoload :DescendantsTracker
...
在很多gem中也会用到Autoload。比如simple_form
module SimpleForm
extend ActiveSupport::Autoload
autoload :Helpers
autoload :Wrappers
eager_autoload do
autoload :Components
autoload :ErrorNotification
autoload :FormBuilder
autoload :Inputs
end
def self.eager_load!
super
SimpleForm::Inputs.eager_load!
SimpleForm::Components.eager_load!
end
end
这些autoload和原生的ruby的autoload是一样的么？这个eager_autoload和eager_load!到底做了什么？
下面分析啊下Autoload的代码：
require "active_support/inflector/methods"
module ActiveSupport
# Autoload and eager load conveniences for your library.
#
# This module allows you to define autoloads based on
# Rails conventions (i.e. no need to define the path
# it is automatically guessed based on the filename)
# and also define a set of constants that needs to be
# eager loaded:
#
# module MyLib
# extend ActiveSupport::Autoload
#
# autoload :Model
#
# eager_autoload do
# autoload :Cache
# end
# end
#
# Then your library can be eager loaded by simply calling:
#
# MyLib.eager_load!
module Autoload
def self.extended(base) # :nodoc:
base.class_eval do
@_autoloads = {}
@_under_path = nil
@_at_path = nil
# 默认情况下_eager_autoload是false的
@_eager_autoload = false
end
end
def autoload(const_name, path = @_at_path)
# 这里很显然Rails惯例大于配置的就在这里实现的，在调用ruby原生的autoload时Rails会帮忙配置path。
unless path
full = [name, @_under_path, const_name.to_s].compact.join("::")
path = Inflector.underscore(full)
end
# 判断@_eager_autoload，true则保持到@_autoloads
if @_eager_autoload
@_autoloads[const_name] = path
end
super const_name, path
end
def autoload_under(path)
@_under_path, old_path = path, @_under_path
yield
ensure
@_under_path = old_path
end
def autoload_at(path)
@_at_path, old_path = path, @_at_path
yield
ensure
@_at_path = old_path
end
# 将@_eager_autoload置为true，然后yield，最后再将@_eager_autoload恢复
def eager_autoload
old_eager, @_eager_autoload = @_eager_autoload, true
yield
ensure
@_eager_autoload = old_eager
end
# 通过这里eager_load!方法将@_autoloads保存的path全部require。autoload在不同情况下就是调用了require或者autoload。
def eager_load!
@_autoloads.each_value { |file| require file }
end
def autoloads
@_autoloads
end
end
end
def autoload(const_name, path = @_at_path)
# 这里很显然Rails惯例大于配置的就在这里实现的，在调用ruby原生的autoload时Rails会帮忙配置path。
unless path
full = [name, @_under_path, const_name.to_s].compact.join("::")
path = Inflector.underscore(full)
end
# 判断@_eager_autoload，true则保持到@_autoloads
if @_eager_autoload
@_autoloads[const_name] = path
end
super const_name, path
end
# 将@_eager_autoload置为true，然后yield，最后再将@_eager_autoload恢复
def eager_autoload
old_eager, @_eager_autoload = @_eager_autoload, true
yield
ensure
@_eager_autoload = old_eager
end
# 通过这里eager_load!方法将@_autoloads保存的path全部require。ActiveSupport的autoload在不同情况下就是调用了require或者原生ruby的autoload。
def eager_load!
@_autoloads.each_value { |file| require file }
end
对于一些lib这样做的好处就是可以利用rails的eager_load在production环境下提前加载，而不是在request请求时加载。
待续。
参考链接：
http://blog.arkency.com/2014/11/dont-forget-about-eager-load-when-extending-autoload/
http://blog.plataformatec.com.br/2012/08/eager-loading-for-greater-good/
http://www.dbose.in/blog/2013/06/09/ruby-notes-autoload/
http://stackoverflow.com/questions/1457241/how-are-require-require-dependency-and-constants-reloading-related-in-rails
