PlacesはFirefoxの履歴とブックマークを保存するデータベースで、SQLiteというデータベース管理システムを利用して、places.sqliteというファイルを生成している。このファイルの肥大化と断片化がFirefoxのパフォーマンスの悪化を招くとみられており、削除されて空いたレコードを詰めて再配置するvacuum命令に関心が集まるゆえんだ。
しかし、Firefoxはこのvacuum命令を自動的には発行してくれない。そのため履歴データやブックマークを削除してもplaces.sqliteの肥大化・断片化は進む一方である。もちろん、多くのユーザーはこのような事態を望んでおらず、Firefoxの速度低下を防ぐ簡単な手段を欲していた。えむもじら『Firefox の places.sqlite を再起動せずに VACUUM する方法』および『Places を VACUUM する拡張機能3個』が人気を博したのは、ユーザーのそうしたニーズに合致したからだと考えられる。
Firefox本体もこのニーズを酌んで、places.sqliteをアイドル時間にvacuumする方向で開発が進められている。以前『Firefox.nextでは自動でvacuumしてくれる？』で構想があることはお伝えしたが、対象をPlacesに絞った「Places Vacuum」と呼ばれるプロジェクトが実際に稼働中だ。
同プロジェクトの目的は、次の三つ。
- places.sqliteの断片化をvacuum命令で解消する
- 外部アプリ（以前のGoogleツールバー）が原因となったデータベースのサイズ問題を解決する
- ひどく断片化したデータベースが原因となったスマートロケーションバーのパフォーマンス問題を修正する
肝心なのは手段だ。vacuum命令の処理には時間がかかる。手動実行にすると使わないユーザーが大勢出てくる一方、自動実行だとFirefoxの通常の動作に支障をきたすおそれが出てくる。開発担当者が選んだのは後者、つまりアイドル時間を利用した自動実行だった（Bug 512854）。
Firefoxは、まず、places.sqliteに統合すべき内容を記録したジャーナルファイルを、vacuum処理中はメモリに待避させておき、処理終了後に書き戻す。高速化に役立つ技法だが、ジャーナルファイルにこうした扱いをしても問題が少ないことは、Firefox 3ユーザーを3.5に移行させる際に検証済みだという。
次に、vacuum処理をメインスレッドから外し、非同期処理を行う。これによって、ブラウザのUIが固まってしまうのを防ぐ。一見すると「アイドル時間に」実行するのだからそこまでする必要がないようにも思えるが、ユーザーが何ら入力を行わずに動画を眺めていることも当然あり得る。同期処理のままだと動画の再生まで止まりかねず具合が悪い。
それでも、あまりvacuumを頻繁に行うのはよくない。いかに配慮してもユーザーのPC環境によってはパフォーマンスが一時的に低下するだろうし、実はデータベースに多少の未使用領域があったほうがレコードの挿入処理が高速になるということもある。
今のところ、未使用領域がデータベースの5分の1以上を占めているかどうかを基準にし、回数は、多くとも1ヶ月に1回に止める一方、少なくとも2ヶ月に1回は実行するとしている。両者の関係は基準のほうが優先されるものとみられ、未使用領域が一定の大きさ以上にならないかぎりは、期間がいくら経過してもvacuum命令は発効されないだろう。
この新機能、遅くともFirefox 3.7で実装されることは間違いない。ただ、プロジェクトのターゲットがFirefox 3.6とされていること、最初のパッチが既にできあがっていることからすると、3.6に間に合う可能性は充分にあるといえよう。
