Issue #5427 has been updated by Yura Sokolov.


> That???s rather meager results (and actual timings say a lot more than percentages).

Yes, I know. Gain were much greater before #5727 were fixed. So that, caching expanded_load_path should be next step of optimization.

> What are the results for smaller $LOADED_FEATURES sizes (say, in the 0..99 range)?

Running 50 times `ruby -r sequel -e 'exit'` is 16.2sec without patch and 16.7sec with patch.
So that, it seems, that patch hurts performance by 0.01sec on each run (or, about 3%) when $LOADED_FEATURES is about 66.

>> But gain should exponentially increase with application size grow.
> Exponentially?

Well, without patch complexity of loading is O(n**2), with patch is O(n*log(n)), so that, gain grows as n/log(n) :)
You eat me :)

> And how much larger of a $LOADED_FEATURES will we ever see?

It seems that 1600 is not uncommon, a man at #5703 has such with moderate application.
----------------------------------------
Feature #5427: Not complex patch to improve `require` time (load.c)
http://redmine.ruby-lang.org/issues/5427

Author: Yura Sokolov
Status: Open
Priority: Normal
Assignee: 
Category: 
Target version: 


Currently `loaded_features` are unsorted, so that `rb_feature_p` ought to iterate over all `loaded_features` to figure: is requested feature loaded?

After this patch `loaded_features` is kept sorted by basename without extension (/usr/lib/ruby/asdf.rb => asdf). When `rb_feature_p` start its check, it goes straight to the first item with matching basename (using binary search) and stops after last.

Methods `$LOADED_FEATURES.<<` and `$LOADED_FEATURES.push` are overriden to keep sort order. `push` accepts only 1 parameter, but it seems that no one pass more to it.

Currently I choose to consider characters of basename in right to left order, but it could be changed, I think.

https://gist.github.com/1272991
https://github.com/ruby/ruby/pull/51


-- 
http://redmine.ruby-lang.org