< :前の番号
^ :番号順リスト
> :次の番号
P :前の記事
N :次の記事
|<:スレッドの先頭
>|:次のスレッド
^ :返事先
_:自分への返事
>:同じ返事先を持つ記事(前)
<:同じ返事先を持つ記事(後)
---:分割してスレッド表示、再表示
| :分割して(縦)スレッド表示、再表示
~ :スレッドのフレーム消去
.:インデックス
..:インデックスのインデックス
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>