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

Hello, Xavier

http://rhnh.net/2011/05/28/speeding-up-rails-startup-time

In the above article, you said that the bottleneck is to find
$LOADED_FEATURES in linear, but I doubt it.  If you are right,
1.8 should be also slow because 1.8 uses the same algorithm.
Thus, I guess there is another bottleneck.


I tried your patch and test in https://gist.github.com/985224
on Ubuntu.
I could confirm that trunk is twice slower than 1.9.2p180.
But I couldn't confirm that the speed up by your patch.
I also performed the same benchmark after "gem install rails",
but there is no difference.


# 1.9.2p180
$ ruby -v full_load_path_benchmark.rb
ruby 1.9.2p180 (2011-02-18 revision 30909) [i686-linux]
      user     system      total        real
0 in load path  0.000000   0.000000   0.000000 (  0.003764)
500 in load path  0.040000   0.040000   0.080000 (  0.081142)
1000 in load path  0.060000   0.100000   0.160000 (  0.159599)
1500 in load path  0.130000   0.100000   0.230000 (  0.235893)
2000 in load path  0.120000   0.200000   0.320000 (  0.317750)


# trunk
$ ../ruby.org -v full_load_path_benchmark.rb
ruby 1.9.3dev (2011-05-30 trunk 31824) [i686-linux]
      user     system      total        real
0 in load path  0.000000   0.000000   0.000000 (  0.005887)
500 in load path  0.090000   0.110000   0.200000 (  0.208288)
1000 in load path  0.160000   0.250000   0.410000 (  0.406125)
1500 in load path  0.200000   0.370000   0.570000 (  0.586779)
2000 in load path  0.240000   0.500000   0.740000 (  0.749551)


# Xavier patch
$ ../ruby.new -v full_load_path_benchmark.rb
ruby 1.9.3dev (2011-05-30 trunk 31824) [i686-linux]
      user     system      total        real
0 in load path  0.000000   0.000000   0.000000 (  0.006294)
500 in load path  0.080000   0.210000   0.290000 (  0.293921)
1000 in load path  0.190000   0.390000   0.580000 (  0.585095)
1500 in load path  0.290000   0.540000   0.830000 (  0.839902)
2000 in load path  0.370000   0.740000   1.110000 (  1.114302)

-- 
Yusuke Endoh <[e-mail]>