The falcon patches for 1.9.3 together with GC tuning boosted our rails loading time by over 400% (Thanks to the answer on http://stackoverflow.com/questions/12892937/improve-rails-lo...). It's easy to see how required gems add up to the loading time, so I hope to see some more improvements.
This affects a lot of things: going into the console, running the server, running tests, running migrations, rake tasks etc...
Not trying to start a flame war, but I recently compared a live rails project with another live django project I was working on. Django was loading in under 1 second. Rails took almost 50 on a similar-spec host. Apples and Oranges. I know. After applying the falcon patches it dropped down to around 11 seconds. There's still an order-of-magnitude difference, but it's nice to see things going in the right direction.
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.
This affects a lot of things: going into the console, running the server, running tests, running migrations, rake tasks etc...
Not trying to start a flame war, but I recently compared a live rails project with another live django project I was working on. Django was loading in under 1 second. Rails took almost 50 on a similar-spec host. Apples and Oranges. I know. After applying the falcon patches it dropped down to around 11 seconds. There's still an order-of-magnitude difference, but it's nice to see things going in the right direction.