[ruby-dev:18139] Re: autoload patch for ruby-1.7

At Sun, 1 Sep 2002 15:53:24 +0900,
Minero Aoki wrote:
> 実はこの点に関しては GC の影響もあります。ファイルをロードした
> 後には必ず GC が起動されるので、ファイル数が増えるとロードがか
> なり遅くなるんです。Bison が使えるなら ruby.c の load_file() に
> ある rb_gc() を消してみてください。一気にロードしてもかなり速く
> なると思います。(ただし Bison 以外でこれをやると最悪 SEGV します)

なるほど。試してみると、おっしゃる通り、相当速くなりますね! よく事情が
分かってないんですが、Bisonでコンパイルしたparse.cを配布する、あるいは、
Bisonでコンパイルすることを前提にするのは良くないんでしょうか？Bisonは
1.24から出力には何の制限もしないという方針に変更したので、ライセンス的
には問題ないように思えるのですけど。

At Mon, 2 Sep 2002 00:58:26 +0900,
[e-mail] wrote:
> definedは修正する必要はないんじゃないでしょうか。

私もそう思って、自分なりに実装していたんですが、

> 確かめたわけじゃありませんが、ファイル名とシンボルの配列をキー
> にするよりも、st_tableを各モジュールに持たせたほうが速いような
> 気がします。

これなら中田さんのパッチの方が優れていますね。

実を言うと、中田さんのパッチにも私のパッチにも、というか、元の師星さん
のパッチに、非互換性の問題が一つ、重大なバグが一つあります。非互換なの
は、オリジナルでは、

autoload :Foo, "foo.rb"
autoload :Foo, "bar.rb"
p Foo

とした時、bar.rbがロードされるのに対し、パッチではfoo.rbがロードされて
しまいます。これは簡単に直せると思います。

バグの方ですが、

autoload :Foo, "foo.rb"
autoload :Bar, "foo.rb"
p Foo
p Bar

のように、一つのファイルに複数の定数が定義されているとき、それぞれに
autoloadを呼ぶと、一つ目は成功しますが、それ以降は失敗することです。こ
れはautoload_deleteが実際のロードのきっかけになった定数しかst_deleteし
ないことが原因だと思います。

それなり速くて素直なのは、逆方向のハッシュテーブルを別に持ち、あるファ
イルからautoloadされるべき定数のリストを簡単に見られるようにしておく方
法です。この方法を使うと、データを重複して持たないといけなくなるので、
あんまり良くないかもしれません。

少々遅くても良いなら、テーブルを全検索して、同じファイルからロードされ
る定数を見付ける方法もあります。これだとautoloadされる定数が1000とかに
なると(そんなことはあり得ないとは思いますが)、すごく遅いと思います。

あまり良いアイディアが浮かばないので、代案をいただけるとありがたいです。

おくじ