メソッド定義の対象となるクラスを指すruby_classと、定数参照の対象となるクラスを 指すruby_cbase(その実態はruby_cref)は、非常に似通っている。というか、このふたつ って本来は統一した方がわかりやすいんじゃないだろうか。きっとユーザーもそれを期 待してると思うし。
ということで、統一する。今回はruby_classを全削除して、 ruby_cbaseに置き換えるこ とにする。
で、思い立ったら３０分で作業が終了してしまった。今まで１０年以上これらスタック と格闘してきたのは一体なんだったんだろう。
というわけで、1.9ではスタックを３本削減。残るは以下の５本。
これらも手を入れる余地はありそうな気がする。たとえばprot_tagを一つ一つジャンプ しながらチェーンするのではなく、目的の場所までいっきにジャンプするとか。 ruby_dyna_varsをリンクではなく各レベルごとの配列にするとか。
昨日の高速化パッチは高速なんだけど、どうやらN-GramのインデックスになっているBDBの更新に問題があるようで、検索結果に大きな漏れがある。morqのようなタイプのメールリーダーでは検索以外にメールに到達する方法が無いので、漏れは致命的だ。
しばらくソースを眺めてみたが、かなり大規模な修正で、どこに問題があるのか発見することはできなかった。
しかたがない。このパッチは当面断念しよう。
で、パッチを当てる前のRastのソースを眺めてみる。とりあえず遅いのはsyncする部分のようなので、そのへんを重点的に。
まず、明示的なfflush(3)とBDBのsyncはおそらく不要なので外すことにする。 stdioの方はfseek(3)を呼んでいるのでそのタイミングでflushされているはずだし、 BDBの方も明示的にsyncする理由はなさそうだ。BDB自身に任せた方が賢いsyncをしてくれるだろう。
次にソースをよく読むと、データファイルの書き出しで、各N-Gramごとに fseek+fread+fwriteを繰り返している。
デバッガで実行してみると、 syncの遅さはどうやらここに由来しているようだ。プロファイラまで動かせると確実なんだが、 Rubyで書いてあるmorqからRast部分だけのプロファイルを取る良い方法を知らないのだ。
というわけで、できればここをページ単位での書き出しにしたいところ。
だが、なかなか良いアイディアが思いつかない。
いっそ、現在の「BDBによるインデックス＋データファイル」という構成から「全部QDBM」にしてしまうってのはどうだろうか(QDBMS好き)。
Curiaを使えば、データ容量の問題もさほどではなさそうに思うし、素朴に要素ごとにfeek+read+writeするよりは、 (ページングしてるから)速度的にも、(圧縮してるから)容量的にも有利だと思うんだけど。
でも、確かRast設計段階でこのアイディアはボツにされたんだよな。ま、単なる「上司の思いつき」だったので、その時は強くは出なかったんだけど。自分が作業するわけじゃないから、当事者の意見の方が重要だしね。
でも、担当者が忙しい今のうちに、こっそり試してみるか*1。
はっ、...もう２月か。原稿の〆切が近づいているぞ。もうちょっと先まで我慢したほう がよいか。
追記:
後でQDBMのソースを読んだら、DepotやCuriaはデータ圧縮してなかった。容量的な利点 は無いようだ。
*1 ここに書いたら全然「こっそり」じゃないなあ
教会の宣教師による英会話を手伝ってくる。
今日は「英語によるスキット」。我々の班(６名)は、即興で「三匹の子豚」を演じたの だった。急だったわりには全員ノリノリだったという。
確かに結構楽しかった。
降ってきたよ。7時前に帰宅したときには降ってなかったのに、 7時10分に英会話に出発 しようとしたら、わずか２０分ほどで地面が真っ白になっていた。
明日の温泉は大丈夫かな。寒い方が風情が出るけど。
そして、明日こそは安来苑の温泉に入ろう。古くからインターネット接続完備の温泉旅 館として(知る人には)知られている安来苑では過去数回宴会を行っているのだが、私は いずれもハックに熱中していて、温泉に入りそこねているのだ。
明日こそは。明日の「Ruby温泉ミーティング」こそは。
今日になってからFirefoxを始めとするいろいろなプログラムが起動に失敗して coredumpするようになる。どうもフォントに問題があるらしい、と気がつくまでずいぶんかかった。
strace付きでFirefoxを起動して、フォントファイルの読み込みあたりで落ちていることでようやくわかった。その後、fc-cacheも落ちるので、これもstrace付きで実行させ、原因がttf-arabeyesというTrueTypeフォントであることを突き止めた。
そういえば何日か前にdselectでチェックを入れたような気がする。
もともと不要だったので、さくっと削除。やっと通常通りに動作するようになった。しかし、こんな問題が起きるようでは、まだまだ「コンピュータは難しすぎて使えない」ものだよなあ。普通の人がこんな問題に直面したら、対処しようがないじゃん。
答え: 「普通の人」はDebianを使いません。
ま、それは冗談としても。うちの妻のマシン(OSS貢献者賞でもらった日立のPrius)は、ネットワークが接続しているのに、「サーバーが見当たりません」というエラーをしばしば出す。どうやら、DNSがおかしいように思うのだが、ネットワークの仕組みはわかっていても、 Windows XPの仕組みがわからないので直しようがない。ネットワークの「修復」を行うと再接続をして、一時的には状況は改善するのだが、すぐに再発してしまう。
Debianでそんな問題起きたことがない(あるいは問題と意識する前に復旧できる)んだけどなあ。