On 9 Jul 2010, at 17:25, Luis Lavena wrote: > On Wed, Jul 7, 2010 at 12:27 PM, James Tucker <jftuc...@gmail.com> wrote: >> Hey all, >> >> I've started work on a branch to reduce the runtime resource usage by >> loading rubygems.rb. Some of you are already aware of this [1]. >> >> The main 'cheat' in the branch so far is to move plugin loads into the >> command manager, but I'm not entirely satisfied with this, and so I'm >> polling for interest in what features plugin authors actually need / want, >> and where those can be injected. Most specifically, I want to see if they >> can be done so more lightly. >> >> Initially, probably the most commonly used plugin is the gemcutter plugin, >> which provides commands. At present it deliberately loads the >> CommandManager, which results in loading in about 37 files and the spec >> cache into memory whenever rubygems.rb is loaded. The difference in startup >> performance is significantly over an order of magnitude on common developer >> systems (with largish numbers of gems installed). >> >> A solution for command plugins would be to have plugins simply register a >> list of files that should be loaded when commands are going to be invoked. A >> continuation of this idea leads to an API something along the lines of: >> >> Gem.register_plugin(:install, 'some_plugin/gem/installer') >> Gem.register_plugin(:command, 'some_plugin/gem/command') >> > > Wouldn't be more appropriate Gem.register_command(:push, > 'path/to/gemcutter/plugin') ? > > After all, you're registering commands, since the plugin loader has > already been started.
Special casing for some hooks is fine, yes. Obviously the hooks for plugin initializations don't override or replace hooks for specific things, like pre_install / post_install, etc. I'm also looking into adding new hooks for certain things so that other things can be registered more correctly (e.g. http://github.com/erikh/hanna/blob/master/lib/rubygems_plugin.rb) >> Such that rubygems could contain simple internal hooks to load these on >> demand, rather than ahead of time, avoiding pre-activation of plugins and >> the current increased cost of loading rubygems. >> > > I like this, a lot. > >> My end goal with this is to aim to get rubygems.rb fast and light enough >> that it could be used for the core integration in 1.9, to avoid the >> remaining and otherwise unavoidable bugs in gem_prelude.rb. >> >> Other work that will be included in this, is indexing the paths to >> rubygems_plugin.rb files, and reducing the resource requirements for >> activation, by having a lightweight version and index set that can be used >> by Gem.activate in place of the current heavyweight Gem.spec. >> > > 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). _______________________________________________ Rubygems-developers mailing list http://rubyforge.org/projects/rubygems Rubygems-developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
