In Rails 5 development mode is going to be a tad snappier for large code bases.

As you know, when a request comes in Rails reloads¹ applications in development mode² if something has changed. The way this is done has evolved over the years.

For a long time Rails simply reloaded unconditionally in every request.

Rails 3.2 improved that with the implementation of a file system monitor which (mod details) walks the application tree on every request checking mtimes.

That tree walk is done per request, not per page view. In particular, it happens when serving each one of the assets so, albeit walking an application tree once may not be a big deal, it may add up depending on the number of assets and how large is your code base.

Rails 5 is going to ship also with an evented file system monitor. When something changes the operating system calls Rails asynchronously and a flag is toggled. When a request comes in, the flag is checked, done.

This monitor is disabled by default, applications may opt-in just loading the listen gem in their Gemfile:

group :development do
  gem 'listen', '~> 3.0.4'
end

On Linux and Mac OS X there are no additional dependencies, but some are required for *BSD and for Windows. Note that some setups are unsupported.

Even if the evented monitor is enabled, the console still needs manual reload because it could be surprising that classes change behind the scenes while there are objects already instantiated. Better be explicit.

Thanks to Puneet Agarwal, who wrote the initial patch for this feature as part of this year’s GSoC.

Also kudos to the listen authors and maintainers, thanks to listen this was infinitely easier to implement in a portable way.

¹ For a technical explanation of what “reloading” means please check the Autoloading and Reloading Constants guide.

² Technically when config.cache_classes is false.