snailgun is an attempt to speed up Ruby command-line startup for
applications which require large number of libraries (like Rails). It
preloads the libraries into a process, then forks that process each
time a new instance is required.
The code, and a couple of simple usage examples, are at
I can demonstrate script/runner starting in about one-quarter of the
normal time, for an empty rails app.
However the code is far from usable at the moment - in particular, I
don’t know why it doesn’t work properly with rake test where the
benefit could be felt most. It also only works under Linux/BSD. I’m
releasing this prototype in case anyone thinks there is mileage in
this approach and might want to take it further, or tune it to work
better with Rails.
At the moment, I’m only preloading the Active* and Action* libraries.
I can’t even use the logic from Rails::Initializer to do this, because
config/boot.rb checks for defined?(Rails::Initializer) to decide
whether to continue or not. There is still a lot more work done by
Rails::Initializer which I think could be re-used.
So, to get maximum benefit from this approach, it may make sense to
refactor Rails::Initializer into two parts:
(1) everything that’s safe to preload - i.e. is independent of ENV and
is very unlikely to be changed between requests (e.g.
RAILS_GEM_VERSION, configured frameworks, gems, plugins)
(2) everything that depends on ENV (for example, the conditional
requiring of ‘active_support/whiny_nil’), and all the user’s
application code
In this case, everything in (1) can be preloaded into the master
image, and then after each fork stage (2) can be run.
An alternative approach would be to start separate processes for
‘test’ and ‘development’ environments, so they can both run the
initializer to completion. This would give the maximum speedup, and as
long as you set config.cache_classes = false in the test environment,
I think it should be safe. The awkward bit is then making all the
tools dispatch to the correct process (e.g. script/console, script/
runner, rake test etc). That is: if the environment says there is an
preinitialized Ruby process then use that, rather than loading config/
boot.rb. A third process with just ‘rake’ preloaded could also be
available.
Regards,
Brian.
P.S. The name “railgun” would have been more obvious, but
unfortunately it has already been taken by another project 