Ruby 2.0 patch that could make Rails startup 2.2x faster

I don't recall seeing a definitive reason given but I'd always assumed it was because Xavier's patch was very large and the Ruby core team are usually conservative with these things. The solution they came up with was merely a few lines of C. It was a bit of a cheap hack but provided much (but not all) of the real world benefit, so they went with it as it was easier to audit.

Check out spork - https://github.com/sporkrb/spork. It keeps your rails code running so that you can run tests fast. Great for development, saved me 11 seconds every time I ran rspec.

The comparison is there in the ticket comments

Hi, patch author here. Two of the falcon patches address the same two issues as my patch series. One caches the expanded $LOAD_PATH (which is expensive to compute mainly because it involves allocating a lot, typically hundreds of KB, and the Ruby GC isn't very efficient), which my patch #4 does. Another speeds up searching the $LOADED_FEATURES array -- his patch keeps it sorted, while my #3 leaves the array unchanged but maintains a hash table pointing into it.

The main difference between the patches is how we maintain the needed invariants, as both $LOAD_PATH and $LOADED_FEATURES are visible to Ruby code and actually mutable from Ruby code. The falcon patches put singleton methods on each of those arrays, wrapping the methods that mutate arrays in order to make them maintain the invariant. This is a very general approach that could implement any desired behavior, but it is relatively complex in the number of cases it has to explicitly handle.

My patches instead take advantage of a feature of the Array implementation to keep a snapshot of each of $LOAD_PATH and $LOADED_FEATURES, and on each 'require' call detect whether they've been mutated. If they have, we rebuild our invariants. This has an advantage in simplicity -- the Array implementation already must track when an Array is mutated, and we just piggyback on that. It can cost more time, but never much more than the status quo (where we must effectively rebuild all the state on every 'require' call), and in normal usage people rarely mutate $LOADED_FEATURES at all and mutate $LOAD_PATH in only one or a handful of bursts, rather than alternating mutation, require, mutation, require many times. So in practice it should be almost as fast as if we never had to rebuild.

NB that funny_falcon himself, aka Yura Sokolov, is participating in the bug thread, so you can read his thoughts there.

I'm not sure if I fully understood your comment - You've used Zeus in production?

If in reference to just improving speeds all across the board - recovery after deploy is the #1 priority for me. Rolling restarts feel like unnecessary complexity in deploys.