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 reloads1 applications in
development mode2 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
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
group :development do
gem 'listen', '~> 3.0.4'
On Linux and Mac OS X there are no additional dependencies, but some are
required for *BSD and for
Windows. Note that some setups
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
Also kudos to the listen authors and
maintainers, thanks to
listen this was infinitely easier to
implement in a portable way.
1 For a technical explanation of what “reloading” means please check the
Autoloading and Reloading Constants guide.
2 Technically when
config.cache_classes is false.