Findings for startup
* RubyGems init time is mostly a result of poor cold Ruby execution
perf; very difficult to improve. Speeding up parses can help somewhat,
but there's a limit to how much we can do to improve cold perf.
RubyGems just plain runs a lot of code on boot, and slow cold
execution perf = slow RubyGems boot
* Running an NG server does not improve Rails boot time very much, but
I have not figured out why. The strongest culprit is excessive
overhead/logic in LoadService. Reducing the number of suffixes or load
path entries searched seems to help, but we still never get close to
MRI. Given that our interpreter and core classes *should* be faster
than MRI after warmup, there's something not warm-uppable causing perf
to stay poor.
* Setting a higher -Xms seems to improve perf by 10-15% on require
'config/environment.rb', reducing the number of incremental and full
GCs by half. The default size, when used for this loading process,
appears to grow several times before the booting is complete.
* RubyGems activation procedure for gems is to add all their loadable
paths to $LOAD_PATH. This causes load path to grow to include several
dozen entries when running Rails. As a result, the already inefficient
searches in LoadService are multiplied by the number of activated
gems, which with Rails can be a very high number. Add to this the fact
that we search .class, .rb, and .jar for every failing entry, and at
least .class and .rb for even successful entries, and it all adds up
very quickly.
* Failed requires of a file (not counting classloader searches)
constructs at least two java.io.File and two JRubyFile objects. File
objects normalize the paths on construction as well as query the
platform-specific FileSystem object for the file's prefix (for
absolute path logic). JRubyFile itself constructs at minimum one more
JavaSecuredFile and at maximum two more, all of which are java.io.File
descendants. Ultimately for a failed require we construct and
normalize from 6 to 8 File-related objects, and call isAbsolute at
least twice. Successful requires construct almost as many File
objects.
* LoadService is grossly inefficient, repeatedly constructing filename
+ ext, repeatedly checking that name for absolutism and more. In order
to clean it up, it needs a major overhaul/redesign.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
