アナログ
RSS  

Firefox 3:VACUUMで劇的に起動が速くなるのはファイル断片化解消のせい?2009/08/14 23:23

1日使った後のplaces.sqlite
ふと好奇心からplaces.sqliteが1日でどのくらい断片化するのだろうとデフラグしてから様子を見てみました。

私はファイルの断片化を避けるために、プロファイル用パーティションに置いていますので、システムドライブよりは断片化しにくいと思われますが、それでも14に断片化してました。

仮に履歴の最長保持期間(デフォルト180日)まで保持されたとすると
1+13×180=2341
2341も断片化したDBを1.8インチとか遅い頃の2.5インチHDDで読込んだら起動に1分かかってもおかしくないかなと(半年もデフラグしてないとか、すごくアレな前提ですけど)。

逆に当時私は、定期的にデフラグしてる上にIDE 3.5インチ7200RPMのHDDでしたので、2、3秒しか変わらなかったのも納得できます(数MBのファイルの読込でそんなに変わるわけがない)。
まして履歴の読込が遅いFirefox 3.0.x系だとなおさら顕著になるように思えます。

検証するにはFx 3.0.13にした上でplaces.sqliteを断片化する(さらに遅いHDDも)必要がありますが、さすがにそれは面倒すぎるのでちょっと勘弁。

仮説はあくまで仮説w
なんにせよ、places.sqliteはあまり太らせないのが吉かと。
最近は4MB以下に抑えるコツもつかめたのでVACUUMもしてなかったり。
(それよりVACUUM後はブックマーク管理でFxがクラッシュしやすくなりません? 本当はそれで止めたのですけど ^^; )

コメント

_ 結城 ― 2009/08/15 00:29

使っているのはDefraglerでしょうか。

Operaの履歴全文検索用インデックスファイルがひどいですよ。
気がつけば200~300近く断片化しています。
あまり頻繁にOperaを使わない上、デフラグも1週間に一度(ファイル単位ですが)しているにも関わらず...。

_ puppet ― 2009/08/15 00:41

結城様

|使っているのはDefraglerでしょうか。

そうです。他にUltraDefragも使ってます。

|気がつけば200~300近く断片化しています。
それもひどいですねぇ。

places.sqliteはFirefox 3.0だと起動時間に大きく影響してますので、一時期結構な話題になってたと思います。
Fx 3.5で多少軽減され、3.6で高速化されてます。
いずれ自動VACUUMも実装するという話ですので、この話題も最後かなぁとw

コメントをどうぞ

※メールアドレスとURLの入力は必須ではありません。 入力されたメールアドレスは記事に反映されず、ブログの管理者のみが参照できます。

※投稿には管理者が設定した質問に答える必要があります。

名前:
メールアドレス:
URL:
次の質問に答えてください:
スパムがウザイので合い言葉を入れるようにしました。山と言えば川だろJK


コメント:

トラックバック

このエントリのトラックバックURL: http://puppet.asablo.jp/blog/2009/08/14/4514714/tb

※なお、送られたトラックバックはブログの管理者が確認するまで公開されません。