[ruby-core:31074] Re: [Bug #3140] gem activation has changed between 1.8 and 1.9

On 6 Jul 2010, at 10:14, James Tucker wrote:

> 
> On 6 Jul 2010, at 08:22, Roger Pack wrote:
> 
>>> I have to agree.  I'm still trying to figure out the utility of
>>> gem_prelude while sifting through code and attempting to resolve this
>>> issue.
>>> 
>>> Why do we have gem prelude?
>> 
>> Because it allows us to avoid loading full rubygems, which takes quite
>> awhile on windows and jruby, and in general loads a lot of unnecessary
>> functionality [1]
> 
> I'm working on fixing this, if I could be allowed a little more time to generate a plugin load index and cut down the size of the spec cache for the sake of activation, then I could even remove the hack required to get this down to pretty much prelude speed (skipping plugin loads). As it is, I've got rubygems/fast.rb in the following branch within the same order of magnitude as gem_prelude, and doesn't break any of rubygems functionality apart from plugins (which are also violated by prelude). Furthermore this option will respect 3rd tier package manager patches, which is important if we're ever going to recover compatibility and communication folks like the Debian maintainers (something which I am working on too).
> 
>    http://github.com/rubygems/rubygems/compare/master...perflude
> 
> This patch set so far also massively reduces the immediately loaded file list:
> 
>    raggi@mbk: ~/dev/ext/rubygems % ruby -Ilib -r rubygems/fast -e 'puts $"' | wc -l
>           7
> 
> Although this may not be "as light" as prelude (it is really damn close), it is semantically correct and should avoid the untold issues that users are already having due to prelude, and largely misunderstanding.

I forgot to include simple benchmark examples:

http://gist.github.com/463942