CJK Indexing

Mozilla Fluxが変な煽り(ネガティブな意味じゃないです)と某所で相談されたので、sqlite3のコードを見ながら実装を考えた。そのときのメモ。

現在のsqlite3の場合、サーチインデックス自体は、FTS3と呼ばれるモジュール構造を使って実装することが可能で、これは検索ワード用の別のテーブルを作ることでインデックスを実現している。

で、AndroidとかMacOS XのSpotlightとかだと、libicuというIBMの作った多言語ライブラリを使っている。これは、WebKitでも使っているので、WebKitベースのブラウザだとこれを使うことでの(コードサイズやメモリ使用量的な)コストはないに等しい。そのため、libicuは使うことにはWebKit的にはネガティブにはならない。

ただ、これがGeckoだと話が別。

外部のOSSのコードを持ってくるとき、Mozillaなやり方だとスタティックリンクで持ってくるのが普通なんだけど、これは非常にコードサイズを増加させてしまう。なので、libicuをそのまま使うということはよくない。

ただ、MacOSの場合は、OSでlibicuを持っているので動的にロードして使うことで、メモリ使用量の増加はたかが知れている。Linuxだと環境に依存する(この場合はある意味無視したほうがいいけどね)。Windowsだとこのライブラリを持ってないため、コスト面で不利。なので、libicuを使うことは諦めた。storage周りやっているShawnもlibicu使うことは否定的だしね。

また、Windowsだと、Indexing Serviceのワードブレーカーを使うコードを試したところ、速度面は問題ないのだけどブレーカーの精度の部分で納得いかず保留。それにプラットフォームでいろいろ変更するのは、Mozillaらしくない。

なので、porter+CJKのみbi-gramという方式で実装してみたところ、自分のメール環境で1.5倍のデータベースサイズの増加 (今まではCJKはブレイクなし) + 速度 (Althon64 X2 2.2GHz <- メイン開発環境)も問題を感じないので、それでテストパッチを作成してみた。

今の時期だと正直微妙なので、拡張でも対応可能なレベルで作っているというのが、今回の最大のポイント。

ちなみにMeCabとか使うのは却下。中国語の辞書ってどうするのよ。