私の中では。
そんな訳でスッパリとsqlite3を捨てました。
新しく採用したのはJDBMです。
元々、変換前のテキストと変換後のテキスト(複数の変換候補は'/'区切りの可変長文字列)しかSKKでは必要なかったので、今流行のkey-valueデータストアでまったく問題なかった訳です。
sqlite3からJDBMに更新するためにDicMakerから作り直しとなりましたが、おかげで滅茶苦茶速いです。
入力中の文字列に対応するkeyの集合を得るのも馬鹿みたいに速くなりました。
これにより無事に巨大な静的辞書ファイルをローカルにて使用しつつもsimejiやmigemizeのように入力中に候補文字列を表示することが可能となりました。
JDBMはB+-treeのデータ構造を利用できるkey-valueのデータストアです。
複数のPCに跨る分散環境は構築できませんが、ファイルを用いてpersistentにデータストアを保存することが可能です。
恐らく、sqlite3でも頑張って勉強してパフォーマンスチューニングの腕を磨けばJDBMに負けないパフォーマンスを出すことは可能なのじゃないかとは思います。
しかし現在の私にはsqlite3を必死に勉強するよりはよりデータ構造が単純でその分高速なライブラリを利用することがずっと効率が良いのでした。
Androidは一部のクラスが無くJDKに完全互換ではないので動くかどうか心配だったのですが、jarを追加したら問題なく動きました。
これは非常に大きな気づきであると思います。
AndroidのContentProviderは皮のみが標準であり、中身の実装は通常sqlite3を用いてJDBCにも似たSQLのプログラミングを書かなければなりません。
しかしそのおかげでContentProviderを利用する場合にもsqlite3を使用する必要はありません。
key-valueで代替できる、JDBMで代替できるケースは非常に多いと思われます。
その時、ContentProviderも苦労せずに高速化できる訳ですね！
とりあえずまだ実装がいい加減なので候補表示は使い物になりませんが、Code Googleにはcommitしてしまいます。
辞書とソースの両方を更新してください。
http://code.google.com/p/android-apps-by-minghai/
新しい辞書は以下になります。
SKK_L_dictionary_BTree.zip
修正後のソースはコミットしました。
しかしまだ修正が済んでいないので機能的には先日のものと変わらないと思います。
とりあえず寝てまた修正したらこの日記を含めて改めて修正します。
では、おやすみなさい。
