Firefox 3.5の起動の遅さは、ネックの一つだ。とくに初回起動に時間がかかり、Google Chromeと比べると差が顕著といえる。かといって、Internet Explorerのように部品の一部をOSの一部としてあらかじめ読み込んでおくこともできない。
Firefox 3.6では、地道な改良で起動時間の短縮を目指すことにした。その計画を記したものは、Firefox Sprintsの一環となるプロジェクト、『Startup Time Improvements』のWebページで見られる。要するに、起動プロセスの中でどの処理にどれだけの時間がかかるのかをまず明らかにし、次いでボトルネックになっている部分を解消しようというわけだ。
ただ、劇的なスピードアップはアーキテクチャの大変更を伴わないと達成できないため、今年10月下旬ころのリリースを目指すFirefox 3.6にはとうてい間に合わない。そこまで大仕事にならなくても高速化が図れる部分に手をつける。それともう一つ、処理を遅らせても問題ない個所を起動後に回すことにも取り組む。
何はともあれ、まずは起動プロセスの詳細を明らかにせねばならない。『StartupPatchUsage』では、Bug 480735のパッチを当てたビルドを作成し、Firefoxが起動時の処理とそれにかかる時間をログに残すようにする方法について説明されている。
この問題に取り組んでいる開発者の一人Vladimir Vukicevic氏は、ブログで起動プロセスの分析手法や、初期の結果などに言及する。たとえば、『Startup, again』を見ると、同氏のMac OS X環境で、Firefox（バージョン不明）のウォームスタートが820ms（0.82秒）、コールドスタートが11200ms（11.2秒）だという。大雑把にいえば、初回起動がコールドスタート、二回目以降がウォームスタートに該当する。コールドスタートに時間がかかるのは、I/Oアクセスの影響が大きい。I/Oアクセスとは、これまた単純化するとディスクアクセスのことである。ディスクキャッシュの話をとりあえず脇に置けば、ハードディスク上にFirefoxのプログラムやプロファイルが保存されていると、けっこうな時間が起動時に費やされてしまうわけだ。
I/Oアクセスが高速化されれば、このタイムロスは少なくなる。SSDや、場合によってはRAMディスクでFirefoxを運用できれば、状況はかなり改善されるだろう。
次に、ウォームスタートのケースだが、こちらは『Startup, part 1』で以下のように説明されている。
0.6% XRE startup
0.1% pre-XPCOM startup
12.4% XPCOM, network, app-startup
9.6% CreateHiddenWindow
8.9% EM & cmdline
65.7% Main thread event processing
最後に挙がっている「メインスレッドのイベント処理」が大きな割合を占めている。そこで、この処理を非同期化する作業に取り組んでいるそうだ（Bug 506416）。処理が停滞しなければ、最終的には早くて済むという意味だろう。そのほか、UTF8からUTF16へと文字コードを変換するプロセスも案外時間がかかっており、改良の余地があるとのこと（Bug 506430）。
前記『Startup Time〜』ページの「Scratchpad」欄には検討すべき個所が列挙されており、今後も増えていくものとみられる。限られた期間内での対処という制約があるので、成果のほどはFirefox 3.6がリリースされてみないと分からないものの、Firefox 3.5.xと比べて起動時間が短縮されることだけは間違いない。
