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

Hi all,

On Wed, Jun 1, 2011 at 09:14, Urabe Shyouhei <[e-mail]> wrote:
>> This process creates many objects, i.e., strings. ypically,
>> $LOADED_FEATURES are already expanded, so the process is not
>> needed in normal cases. n fact, 1.9.2 expands the paths only
>> when they are not absolute, like this:
>>
>> $LOADED_FEATURES.map {|f| File.expand_path(f) if f is not absolute }
>
> If it's the actual problem, why not cache the expanded path?
>
> https://github.com/shyouhei/ruby/commit/c229cb4

I did a benchmark > https://gist.github.com/1041791 (full)

Measured loading time of 2 Rails 3.0.7 apps

 * emptyApp: script/rails generate emptyApp
 * slow-rails: by Joe Van Dyk (https://github.com/joevandyk/slow-rails)

Interpreters

 * ruby 1.9.2p274 (2011-06-06 revision 31932) [x86_64-linux]
 * ruby 1.9.3dev (2011-06-22 trunk 32204) [x86_64-linux]
 * ruby 1.9.3dev (2011-06-22 trunk 32204) [x86_64-linux] + Shyouhei's
expand_path cache patch
(https://github.com/shyouhei/ruby/commit/c229cb4)

Results (average wall clock time of 'time ruby script/rails runner 0' 10 times)

 * 1.9.2p274
   * emptyApp:   1.87 [sec]
   * slow-rails: 8.69 [sec]

 * 1.9.3dev of today
   * emptyApp:   1.35 [sec] (39% faster than 1.9.2)
   * slow-rails: 6.37 [sec] (36% faster than 1.9.2)

 * 1.9.3dev + Shyouhei's expand_path cache patch
   * emptyApp:   1.07 [sec] (26% faster than 1.9.3dev)
   * slow-rails: 3.81 [sec] (67% faster than 1.9.3dev)

Awesome result.

Anyone can imagine a downside of this? It could not work as expected
if the result of rb_file_expand_path *changes* during require (adding
a new file during require should work.) Do we need to care such a
case?

Regards,
// NaHi