青木日記

■ 敗北

しばらく我慢していたがついに Mac に GNU ls を入れてしまった。 ls filename -s ってやることが多いんだよね俺……。

(11:21)

■ かずひこさん迎撃飲み会

迎撃。フランスだもんなあ。フランスですよ。 気をつけて行ってきてください。

今回は、かずひこさんの壮大にして邪なる計画が明らかになった。 われわれはいかにしてこの強大な力に抗えばよいのであろうか。

akr さんから net/http が遅ぇー、 とのお達しがあったので手抜きコミット。 とりあえずバッファサイズを 1KB → 16KB にしてみた。 なんで select やめたのか調べて、問題なさそうならselect に戻すかな。

モテへの道：最初の飲み会でプロポーズしてはいけない。

(11:56)

■ size = 26

ruby-reference-manual-diff って ML 名はどう考えても長すぎる。 refm と refm-diff でいいよ。

(23:01)

■ ReFe2 の高速化 (1)

リファレンスマニュアル計画。 @param とかの仕様を決めたまま実装してなかったので サクッと実装しますか、と思ったのだが、 refe s i とかやると無限ループかよ、 ってほど時間がかかることに気付いてしまった。

s で始まるクラスはすごい多いし、 i は Object のメソッドにひっかかるので、 組み合わせでものすごいたくさんのメソッドにマッチする。 で、そのものすごいたくさんのメソッドを 全部ロードして線型マッチするので遅い、 ということらしい。どちらかと言えば特にロードが遅い。 新 ReFe では、とにかくロードするエントリ数を押さえることが勝利への鍵である。

■ ReFe2 の高速化 (2)

• 継承したメソッドをキャッシュしてるのにキャッシュを読んでなかったのを修正
• キャッシュの持ちかたを変えてファイルアクセスを減らすようにした
• 名前だけの段階で限界まで候補を減らすようにした
• マッチした名前が多すぎるときはどうせ一つには決まらないので丁寧な絞り込みをやめた
• webrick/config の gethostbyname で 0.1 秒くらい損してたので、 必要ないときは require しないように変更した

これで現状見付かっている最悪のケースでこのくらいまで抑えた。

~/c/bitclust % time refe2 -d db.big s i >/dev/null
refe2 -d db.big s i > /dev/null  0.24s user 0.05s system 98% cpu0.290 total

普通はもっと候補が少ないので、もうちょい速い。

~/c/bitclust % time refe2 -d db.big arr map >/dev/null
refe2 -d db.big arr map > /dev/null  0.13s user 0.05s system 97% cpu0.181 total

この速度はかなり限界っぽいよ。

(02:54)

■ りふぁれんす

http://doc.loveruby.net/refm/api/view/class/Array

全体的に見ためを変えて、一覧ページでは要約だけ出すようにしてみた。

継承したメソッドもいちおう表示してはみたけど、 private メソッドを削ってないせいでエントリが無駄に多い。 system とか出てるし。 コードを改善するまでは名前だけにしておこう。

……というか、同じクラスのメソッドまで出てるなこれ。 なんでだ。

Object のメソッドがえんえん継承されるのも微妙に不便だなあ。 しかしなければないで困るような気もする。

クラスごとにまとめるかなあ。

名前をキーにして継承したメソッドを 全部同列に並べるオプションも欲しいところだ。

■ りふぁれんす (2)

そして @param 関係はまたしても先送りにされている罠

(03:09)