From: Hiroshi Nakamura Date: 2011-06-23T12:08:46+09:00 Subject: [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 wrote: >> This process creates many objects, i.e., strings. �Typically, >> $LOADED_FEATURES are already expanded, so the process is not >> needed in normal cases. �In 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