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.
>>=20
>> Why do we have gem prelude?
>=20
> 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.