Firefox 3.5は、履歴とブックマーク（Places）、クッキー、フォームの履歴、パスワードといったさまざまな場面でSQLiteのデータベースを使用している。スマートロケーションバーを便利に使えるのもこのSQLiteデータベースのおかげだ。
しかし、厄介なことに、このデータベースはレコードを削除してもそれだけでは占有スペースが変わらない。だからたとえば「このサイトの履歴を消去」で履歴をたくさん削った場合、データベースファイルがコンパクトになるかというと、ならないのだ。このファイルの肥大化が、Firefoxの動作速度を落とす一因になっているといわれている。
新秀の介の日記(2009-07-02)で紹介されているBug 403702は、「LibraryのOrganizeメニューにCompactなるコマンドを追加して、places.sqliteをコンパクトにしよう(VACUUMコマンドを発行する)というもの」。SQLiteのvacuumは、削除されて空いたレコードを詰めて再配置する命令で、これをやって初めてファイルが圧縮される。軽快な動作を取り戻すべく、そうした処理が簡単にできるようにしてほしいとの要望が出るのは自然な流れだ。
Mozillaとしても、状況はもちろん把握している。フロントエンド開発チームの小プロジェクトを集めたFirefox Sprintsの中に、『App-wide Database Vacuum』という項目ができたのがその証拠である。このプロジェクト、まだ担当者も決まっておらず構想の段階だが、次のように説明されている。
「Firefoxが作成したSQLiteデータベースを定期的にvacuumする」。
Placesに限定していないところが一つのポイントだが、他にコンパクトになって恩恵を受けそうなのはフォームの履歴ぐらいか。Firefox.nextでは、フォームの履歴の表示順をURLの履歴のようにスマートに調整することも検討されているので、ファイルサイズは抑えられたほうが望ましいのだろう。
難しいのは、ユーザーの操作を阻害しないようにしながらこのvacuumを行う手段だ。定期的にファイルをメンテナンスしてくれるのはいいとして、その際Firefoxの動作が固まってしまうのでは、やはり受け入れられないだろう。適切な手立てを見いだせなければ、いつまでも構想のままである。
あるいは、マルチプロセス化が進めば、vacuumに一つのプロセスを割り当てることで解決できるのだろうか。たとえば、データベースファイルのバックアップを作成し、それにvacuumをかけ、成功したらそれを本ファイルと入れ替えるといった形で。
ただ、この処理はFirefox自体がタイミングを見計らって実行するらしい。「目標でないもの」の中に、手動でvacuumするためのUIコンポーネントを加えることが入っている。手動だとよく分からないまま実行するユーザーが出てきて、問題が起きる可能性があるというのだろうか。
とにかく、Firefox.nextでは自動でvacuumしてくれるかもしれない。そうなれば、使っているうちにスピードが落ちる現象は確実に減るはずだ。
