Skip to content
Switch branches/tags
This branch is 213 commits ahead, 9 commits behind Roman2K:master.
Fetch upstream

Latest commit


Git stats


Failed to load latest commit information.
Latest commit message
Commit time

Fix slow Rails development mode via rails-dev-boost

Make your Rails app 10 times faster in development mode (see FAQ below for more details).

Alternative to Josh Goebel's rails_dev_mode_performance plugin.

Alternative to Robert Pankowecki's active_reload gem.


If you are using Rails 3 and newer: rails-dev-boost/master branch.

If you are using Rails 2.3: rails-dev-boost/rails-2-3 branch.

If you are using Rails 2.2: rails-dev-boost/rails-2-2 branch.

If you are using Rails 2.1 or Rails 2.0 or anything older: you are out of luck.


If your app doesn't work with rails-dev-boost:

  • make sure you are not keeping "class-level" references to reloadable constants (see "Known limitations" section below)
  • otherwise please open an issue!

I'm very interested in making the plugin as robust as possible and will work with you on fixing any issues.

Debug mode

There is built-in debug mode in rails-dev-boost that can be enabled by putting this line a Rails initializer file:

RailsDevelopmentBoost.debug! if defined?(RailsDevelopmentBoost)

After restarting your server rails-dev-boost will start to spewing detailed tracing information about its actions into your development.log file.


Why create a similar plugin? Because I couldn't get Josh Goebel's to work in my projects. His attempts to keep templates cached in a way that fails with recent versions of Rails. Also, removing the faulty chunk of code revealed another issue: it stats source files that may not exist, without trying to find their real path beforehand. That would be fixable is the code wasn't such a mess (no offense).

I needed better performance in development mode right away, so here is an alternative implementation.


Rails 3

Usage through Gemfile:

group :development do
  gem 'rails-dev-boost', :git => 'git://'

Installing as a plugin:

script/rails plugin install git://

Rails 2.3 and older

script/plugin install git:// -r rails-2-3

When the server is started in development mode, the special unloading mechanism takes over.

It can also be used in combination with RailsTestServing for even faster test runs by forcefully enabling it in test mode. To do so, add the following in config/environments/test.rb:

def config.soft_reload() true end if

Known limitations

The only code rails-dev-boost is unable to handle are "class-level" reloadable constant inter-references ("reloadable" constants are classes/modules that are automatically reloaded in development mode: models, helpers, controllers etc.).

Class-level reference examples

# app/models/article.rb
class Article

# app/models/blog.rb
class Blog
  ARTICLE_CLASS = Article # <- stores class-level reference
  @article = Article # <- stores class-level reference
  @@article = Article # <- stores class-level reference

  MODELS_ARRAY << Article # <- stores class-level reference

  MODELS_CACHE['Article'] ||= Article # <- stores class-level reference

  class << self
    attr_accessor :article_klass

  self.article_klass = Article # <- stores class-level reference

  def self.article_klass
    @article_klass ||= Article # <- stores class-level reference

  def self.article_klass2
    @article_klass ||= 'Article'.constantize # <- stores class-level reference

  def self.find_article_klass
    const_set(:ARTICLE_CLASS, Article) # <- stores class-level reference

  def self.all_articles
    # caching object instances is as bad, because each object references its own class
    @all_articles ||= [,] # <- stores class-level reference

  article_kls_ref = Article
  GET_ARTICLE_PROC = { article_kls_ref } # <- stores class-level reference via closure

What goes wrong

Using the example files from above, here's the output from a Rails console:

irb(main):001:0> Article
=> Article
irb(main):002:0> Blog
=> Blog
irb(main):003:0> Blog.object_id
=> 2182137540
irb(main):004:0> Article.object_id
=> 2182186060
irb(main):005:0> Blog::ARTICLE_CLASS.object_id
=> 2182186060
irb(main):006:0> Blog.all_articles.first.class.object_id
=> 2182186060

Now imagine that we change the app/models/article.rb and add a new method:

# app/models/article.rb
class Article
  def say_hello
    puts "Hello world!"

Back in console, trigger an app reload:

irb(main):007:0> reload!
=> true

When app/models/article.rb file is saved rails-dev-boost detects the change and calls ActiveSupport::Dependencies.remove_constant('Article') this unloads the Article constant. At this point Article becomes undefined and Object.const_defined?('Article') returns false.

irb(main):008:0> Object.const_defined?('Article')
=> false

However all of the Blog's references to the Article class are still valid, so doing something like will not result into an error:

=> #<Article:0x10415b3a0>
irb(main):010:0> Blog::ARTICLE_CLASS.object_id
=> 2182186060
irb(main):011:0> Object.const_defined?('Article')
=> false

Now lets try calling the newly added method:

NoMethodError: undefined method `say_hello' for #<Article:0x104143430>
	from (irb):12

As can be seen the new method is nowhere to be found. Lets see if this can be fixed by using the Article const directly:

Hello world!
=> nil

Yay, it works! Lets try Blog::ARTICLE_CLASS again:

NoMethodError: undefined method `say_hello' for #<Article:0x1040b77f0>
	from (irb):14

What is happening? When we use the Article const directly, since it is undefined Rails does its magic - intercepts the exception and loads the app/models/article.rb. This creates a brand new Article class with the new object_id and stuff.

irb(main):015:0> Article.object_id
=> 2181443620
irb(main):016:0> Blog::ARTICLE_CLASS.object_id
=> 2182186060
irb(main):017:0> Article != Blog::ARTICLE_CLASS
=> true
irb(main):018:0> Article.public_method_defined?(:say_hello)
=> true
irb(main):019:0> Blog::ARTICLE_CLASS.public_method_defined?(:say_hello)
=> false

Now we've ended up with 2 distinct Article classes. To fix the situation we can force blog.rb to be reloaded:

irb(main):020:0> FileUtils.touch(Rails.root.join('app/models/blog.rb'))
=> ["mongo-boost/app/models/blog.rb"]
irb(main):021:0> reload!
=> true
irb(main):022:0> Blog.object_id
=> 2180872580
irb(main):023:0> Article.object_id
=> 2181443620
irb(main):024:0> Blog::ARTICLE_CLASS.object_id
=> 2181443620
irb(main):025:0> Article == Blog::ARTICLE_CLASS
=> true
irb(main):026:0> Blog::ARTICLE_CLASS.public_method_defined?(:say_hello)
=> true
Hello world!
=> nil

The fix

Code refactor

The best solution is to avoid class-level references at all. A typical bad code looking like this:

# app/models/article.rb
class Article < ActiveRecord::Base

# app/models/blog.rb
class Blog < ActiveRecord::Base
  def self.all_articles
    @all_articles ||= Article.all

can easily be rewritten like this:

# app/models/article.rb
class Article < ActiveRecord::Base
  def self.all_articles
    @all_articles ||= all

# app/models/blog.rb
class Blog < ActiveRecord::Base
  def self.all_articles

This way saving arcticle.rb will trigger the reload of @all_articles.


If the code refactor isn't possible, make use of the ActiveSupport's require_dependency:

require_dependency 'article'

class Blog < ActiveRecord::Base
  def self.all_articles
    @all_articles ||= Article.all
  def self.authors
    @all_authors ||= begin
      require_dependency 'author' # dynamic require_dependency is also fine

Asynchronous mode

By default rails-dev-boost now runs in an "async" mode, watching and unloading modified files in a separate thread. This allows for an even faster development mode because there is no longer a need to do a File.mtime check of all the .rb files at the beginning of the request.

To disable the async mode put the following code in a Rails initializer file (these are found in config/initializers directory):

RailsDevelopmentBoost.async = false

routes.rb potentially not reloading

Since Rails 4.0 ActiveSupport now by default reloads routes.rb file if any other auto-loaded .rb has changed. This behavior is different from all previous Rails versions, where routes.rb had been reloaded only if the routes.rb file itself had been changed. This now results in routes.rb being reloading on all requests in which any other unrelated .rb has been changed, it is in my opinion an unnecessary slowdown, thus rails-dev-boost by default reverts Rails to the pre Rails 4.0 behavior.

To disable this patch and revert to the default Rails 4.0 behavior - put the following code in a Rails initializer file (these are found in config/initializers directory):

RailsDevelopmentBoost.reload_routes_on_any_change = true


Q: Since the plugin uses its special "unloading mechanism" won't everything break down?

A: Very unlikely... of course there are some edge cases where you might see some breakage (mainly if you're deviating from the Rails 1 file = 1 class conventions or doing some weird requires). This is a 99% solution and the seconds you're wasting waiting for the Rails to spit out a page in the dev mode do add up in the long run.

Q: How big of a boost is it going to give me?

A: It depends on the size of your app (the bigger it is the bigger your boost is going to be). The speed is then approximately equal to that of production env. plus the time it takes to stat all your app's *.rb files (which is surprisingly fast as it is cached by OS). Empty 1 controller 2 views app will become about 4x times faster more complex apps will see huge improvements.

Q: I'm using an older version of Rails than 2.2, will this work for me?

A: Unfortunately you are on your own right now :(.

Q: My Article model does not pick up changes from the articles table.

A: You need to force it to be reloaded (just hit the save button in your editor for article.rb file).

Q: I used require 'article' and the Article model is not being reloaded.

A: You really shouldn't be using require to load your files in the Rails app (if you want them to be automatically reloaded) and let automatic constant loading handle the require for you. You can also use require_dependency 'article', as it goes through the Rails stack.

Q: I'm using JRuby, is it going to work?

A: I haven't tested the plugin with JRuby, but the plugin does use ObjectSpace to do its magic. ObjectSpace is AFAIK disabled by default on JRuby.

FAQ added by thedarkone.


Written by Roman Le Négrate (contact). Released under the MIT-license: see the LICENSE file.


Speed up slow Rails development mode




No packages published