On 9 Jul 2010, at 19:36, Charles Oliver Nutter wrote: > On Fri, Jul 9, 2010 at 12:40 PM, James Tucker <jftuc...@gmail.com> wrote: >>> Wouldn't rubygems_plugin.rb do the Gem.register* command and deffer >>> the actual plugin loading script for the command invitation? >> >> Yes, it will defer calling activate and modifying the load path. >> >>> What is the benefit on indexing those, since these were already loaded? >> >> To avoid needing to load Gem.spec in order to execute Gem.find_files, which >> is insanely expensive (relatively speaking). > > FWIW, I wrote up a blog post last night about how to walk the heap, > examine memory sizes, and so on using JRuby. One of the items I called > out were all the Gem::Version objects in memory, and there's other > offenders. If you'd like to do some of that exploration, I'm happy to > help. > > http://blog.headius.com/2010/07/browsing-memory-jruby-way.html > > I'm definitely interested in helping reduce the startup load from > RubyGems. It's the largest (by far) slowdown for JRuby startup, which > drives our users a bit batty.
The real pain is loading Gem.spec. I have a two fold plan for this, initially, try to avoid loading it with rubygems.rb. Later on, I want to cut down the amount of metadata that is even loaded through ruby when just activating gems. Stuff that can really kill you is like having multiple versions of pre 2.0 facets installed, or having rdoc-data installed and so on. I blogged about this back in 2007, although I was more interested in page fragmentation under MRI back then: http://blog.ra66i.org/archives/2007/10/calling-on-the-gc-after-rubygems/ At present, adding GC.start after loading Gem.spec on MRI still actually has quite a significantly positive impact on heap fragmentation, depending on other specific context. > > - Charlie > _______________________________________________ > Rubygems-developers mailing list > http://rubyforge.org/projects/rubygems > Rubygems-developers@rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers _______________________________________________ Rubygems-developers mailing list http://rubyforge.org/projects/rubygems Rubygems-developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
