From: Yusuke ENDOH Date: 2011-05-31T01:58:45+09:00 Subject: [ruby-core:36593] Re: [Ruby 1.9 - Bug #3924] Performance bug (in require?) Hello, 2011/5/31 Yusuke ENDOH : > 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. I investigated this issue with ko1 and tarui-san. Trunk seems to create more objects during require than 1.9.2. These objects are not collected because the benchmark program stops it by GC.disable. 1.9.2: 0.30 sec (w/ GC.disable) -> 0.32 sec (w/o GC.disable) trunk: 0.73 sec (w/ GC.disable) -> 0.48 sec (w/o GC.disable) The first issue is in the benchmark program. Still, trunk is 1.5x slower than 1.9.2 because of the object generation. Each require does the something like this: $LOADED_FEATURES.map {|f| File.expand_path(f) } . 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 } However, the check was removed at r30789, I cannot understand the reason of the change because the commit log is too quiet, but I found [ruby-core:34593] and guess that it motivated the change: > Autoload treatment of absolute paths in $LOAD_PATH containing . or .. I think reverting r30789 is an good solution in the immediate future. -- Yusuke Endoh