Rails 3 - Speed up Console Loading Time

I am wondering if there is any relatively easy way to speed up my console load time, which is starting to approach 30 seconds. I have a lot of subclasses whose methods don't seem to be affected by reload! so I end up opening and closing the console a lot. IRB loads lightning quick.

Do I have too many gems? How do I go about timing the load tasks so I can see what is taking up the most time? As you can see, I've already tried the dev-boost gem to no avail. The app is fine in Passenger, it's just the console loading that bugs the crap out of me. Running on MBP OSX 10.6.6 with 2.4GHz and 4GB RAM. Not using RVM.

Versions:

Ovid$ rails -v
Rails 3.0.3
Ovid$ ruby -v
ruby 1.9.2p136 (2010-12-25 revision 30365) [x86_64-darwin10]

Memory:

Ovid$ vm_stat
Mach Virtual Memory Statistics: (page size of 4096 bytes)
Pages free:                         118818.
Pages active:                       341320.
Pages inactive:                      99490.
Pages speculative:                  310576.
Pages wired down:                   112527.
"Translation faults":             23097323.
Pages copy-on-write:               1270961.
Pages zero filled:                13836659.
Pages reactivated:                      36.
Pageins:                            165761.
Pageouts:                                0.
Object cache: 28 hits of 760846 lookups (0% hit rate)

Gemfile:

source 'http://rub开发者_开发问答ygems.org'

gem 'rails', '3.0.3'
gem 'mysql2'
gem 'foreigner'
gem 'haml'
gem 'capistrano'
gem 'nokogiri'

#web services
gem 'yammer4r'
gem 'ruby-freshbooks'

#authentication gems from nifty generator
gem "bcrypt-ruby", :require => "bcrypt"
gem "mocha", :group => :test
gem 'authlogic'

#dev
group :development do
  gem 'rails-dev-boost', :git => 'git://github.com/thedarkone/rails-dev-boost.git', :require => 'rails_development_boost'
end

#testing
group :test do
  gem 'database_cleaner'
  gem 'cucumber-rails'
  gem 'cucumber'
  gem 'rspec-rails'
  gem 'spork'
  gem 'launchy'
  gem 'machinist'
  gem 'faker'
  gem 'capybara'
end

Thank you very much!

I finally found my startup bottlenecks using Benchmark. In particular, navigate to the bundler gem and in lib/bundler/runtime.rb, find the line that does Kernel.require and wrap it like this:

puts Benchmark.measure("require #{file}") {
  Kernel.require file
}.format("%n: %t %r")

You may have to add require 'benchmark' somewhere in your app, like in config/boot.rb. That will show you how long it takes to require each gem. I can't guarantee your results will match mine, but I had a few gems that were taking over a second to load compared with sub-millisecond for most. A few were gems that I didn't need for developing but I did need for some tasks in the development environment, e.g. capistrano, shoulda. I benchmarked other areas of startup (initializers, etc), but couldn't find any significant bottlenecks.

I haven't yet figured out a clean way to configure the app to only load those for tasks where they are really needed. Possibly, I could create an environment called :speedy and use RAILS_ENV=speedy rails s/c for startup when I know I don't need those gems. Then in Gemfile, I could use group :speedy to exclude those gems in certain cases.

All that said, the biggest startup annoyance for me is having to load the entire environment to run a rake task. I could probably exclude most gems for that, but Gemfile would start to get messy so I don't know if it's worth it.

Slightly adapted form that is copy-pastable, wraps all requires, and provides sortable output:

# Add this to the top of boot.rb
require 'benchmark'
def require(file)
  puts Benchmark.measure("") {
    super
  }.format("%t require #{file}")
end

Then you can execute no-op to see them:

rails runner 1

Or sort them and show the top 50:

rails runner 1 | sort -nr | head -n 50

You can speed it up by adding :require => nil to the slow Gemfile entries and require them manually. e.g.

gem 'jammit', :require => nil

I also addressed this issue in a meetup i've had. This seems to be a bug in ruby 1.9.2 (see comments of this patch: https://gist.github.com/1008945)

You can fix it by patching your 1.9.2 by the gist i just linked or upgrading to 1.9.2-head or 1.9.3-head.

This is definitely about cleaning up your code and identifying bottlenecks, but once you've made those savings it's worth looking at something like Zeus to speed up your dev times.

gem install zeus

https://github.com/burke/zeus (docs)

It's not without bugs and does sometimes require a reboot but I am still seeing an overall increase in development times by fast server and console reboots after small code changes.

Very old question & answers, but it's still a useful one...

Somehow have an error with jqr answer, which seems related to autoload (rails 5.2...).

-e:1:in `<main>'                                                                                                                                                                                           
0.002514 require i18n/config                                                                                                                                                                               
.../vendor/bundle-dev/ruby/2.7.0/gems/i18n-1.8.7/lib/i18n.rb:19:in `<module:I18n>': uninitialized constant I18n::Config                                           
Did you mean?  RbConfig (NameError)                                                 

Fixed with this :

# Add this to the top of boot.rb
require 'benchmark'
def require(file)
  mod = nil
  puts Benchmark.measure("") {
    mod = super
  }.format("%t require #{file}")
  mod
end

I can only suggest putting on your lab coat and bisecting the issue. See if commenting out all your gem requirements speeds things up (presumably that'll also involve commenting out pieces of code that rely on those gems). If so, comment out half at a time and so on.

Sorry this isn't a real answer.. You could try ruby-prof I suppose, for example by invoking it with rails runner and a no-op script.

I tried ruby-prof script/rails runner 'nil' on my mac but it appears to have just crashed :-)

EDIT

If you're using git for your app you could try it's bisect command too and see if there's a specific point in time when things got slow, rather than just general bloat.

Reload! has been an issue for some time now. Have a look at this. There are some patches which you could use and some tips on how you maybe able to get around your issue.

The reload method itself looks like this.

# reloads the environment
def reload!(print=true)
  puts "Reloading..." if print
  ActionDispatch::Callbacks.new(lambda {}, false).call({})
  true
end

You could always add you environment to this method to override it function and force the reload you require.

This has worked for me so let us know if it works for you. All the best.

The Bumbler gem is a great little tool for determining gem load speed and identifying slow-loading gems.