Hello,

2011/5/31 Yusuke ENDOH <mame / tsg.ne.jp>:
> 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 <mame / tsg.ne.jp>