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

>=20
> On 6 Jul 2010, at 08:22, Roger Pack wrote:
>=20
>>> 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]
>=20
> 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).
>=20
>    http://github.com/rubygems/rubygems/compare/master...perflude
>=20
> This patch set so far also massively reduces the immediately loaded =
file list:
>=20
>    raggi@mbk: ~/dev/ext/rubygems % ruby -Ilib -r rubygems/fast -e =
'puts $"' | wc -l
>           7
>=20
> 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=