[ruby-core:36859] Re: [Ruby 1.9 - Bug #3924] Performance bug (in require?)

>> Require performance has been imporved a little at r31875, i think.
>
> nice! It sure has.
>
>> Please compare the proposal with it
>
> ine .9.3r31923
> 2000 in load path 0.70 .702834
> 2500 requires 0.29 .676016
> new rails app 1.08 .346
> medium rails app 0.49 10.88
>
> The underlying algorithm is still problematic (see 2500 requires benchmark),
> but I don't have strong evidence that it is affecting performance of real
> apps given it appears to perform well on rails applications. Assuming no
> contrary evidence appears, and without understanding this difference
> further, you probably won't want to apply my patch for a 1.9.3 point release
> given the risk of regressions. I still think it should be given
> consideration for a future major release though.

Thank you for benchmarking. ( I don't have rails benchmarks. )
It is good news that it's effective enough for rails.

I think that your idea is good, and heard Hash is already used in JRuby.
But your patch is large and has some compatibility issue,
so I'm afraid for reject at 1.9.3.


> Out of interest ... how does your commit work? Is it an optimization perhaps
> my patch could benefit from? My concern with r31875 is that it makes that
> loop even harder to understand for those not as familiar with that part of
> the code.

In loaded_feature_path and outer of it,
it takes the match LOADED_FEATURE and LOAD_PATH+target in each of
LOADED_FEATURES and LOAD_PATH array for back compatibility ( i think ) .
before patch, part of matching LOADED_FEATURE and target is in inner loop,
so I only let it out.
LOADED_FEATURE is not matched with target with many case, and patch
makes return fast.

In your patch, cache processing is similar to its feature, and already
optimized.


Regards,
Masaya