Rails startup time optimization

boot.rb

# Instructions for use
#
# 1. Execute "time rails runner nil" a few times in your shell, see how long rails takes to boot
# 2. Add this monkey patch to the top of config/boot.rb
# 3. Repeat step 1.  What's the difference?
#
# This is just an experiment, but it gains me 30% on Rails' start time, which suggests there is something
# in Rails that is breaking the "run only once" behaviour of #require.
#
# Note: You can't override Kernel#require, since Rails by-passes it most of the time.

class Object
  def require_with_dirty_filthy_hack(path)
    return false if (@@__seen ||= {})[path]
    @@__seen[path] = true
    require_without_dirty_filthy_hack(path)
  end

  alias_method :require_without_dirty_filthy_hack, :require
  alias_method :require, :require_with_dirty_filthy_hack
end

Note that my raw numbers are 11.5 seconds down to 8 seconds. It's not scientific, but the difference is big enough that something is worth investigating further.

15.75s avg before
13.61s avg after

13.6% decrease

I smell a Rails pull request coming up.

Ok, nobody use this. It's fine in production where cache_classes is om, but in dev class reloading causes issues. Bummer.

That was my initial thought, but I've been using it since you put it up and haven't run into any issues. What specific case would cause a problem?

I did it, then tested that changing classes works fine fyi

It seems to cause issues for us when modules are mixed into our models at runtime... on subsequent requests after the first one, we start getting "uninitialized constant ModuleName" for whatever is supposed to be mixed in, presumably since the 'require' for the module isn't happening correctly the second time around. Maybe there's another workaround.

Are you using require or include?

require to get the module into scope, include to mix it into the model. Do you mean require or load?

I meant require, wondered why you mentioned it since we're using Rails' autoload and don't require it at all - possibly why it still works.

Ah, I see… yeah, we did a whole bunch of other stuff to prevent gems from loading during Rails startup, so we're requiring the actual gems by hand in some places ;) Il giorno 30/mag/2012, alle ore 16:28, Mal Curtis ha scritto:

…

I meant require, wondered why you mentioned it since we're using Rails' autoload and don't require it at all - possibly why it still works. --- Reply to this email directly or view it on GitHub: https://gist.github.com/2814849