Comments on: Cleaning Up Startup Disk IO

By: Robert Strong

Robert Strong — Wed, 26 Aug 2009 07:31:32 +0000

The extension manager and app update hitting the disk is mainly due to write access check though the hits beyond 1 by app update are mainly do to the way it was original coded. Filed bug 512650 for this

By: BlueMM

BlueMM — Tue, 25 Aug 2009 00:07:44 +0000

Jorge: XPI files are compressed so FF will have to pay the decompression tax while running. Jar files are uncompressed so get the same benefits that Toolkit.jar & browser.jar get (particularly after the recent work Taras has been doing on Jar files).
A lot of extensions package within chrome.jar, but more could (like Stylish etc.)

By: Jorge

Jorge — Sat, 22 Aug 2009 17:08:16 +0000

This makes me think that extension packaging should be redesigned in order to make it more efficient. Don’t forget that extensions are a major reason for startup slowness.

My take on this is that extensions shouldn’t be unpacked in the extensions dir; the XPI should be there instead. Perhaps also the practice of packaging all chrome files in chrome.jar should be discontinued as well, given that in this case there would be one zip nested in another one.

By: .c;fp

.c;fp — Fri, 21 Aug 2009 15:44:03 +0000

Yeah, baby! Firefox 3.5 startup on OS X 10.5 is *so* slow.

By: Standard8

Standard8 — Fri, 21 Aug 2009 07:34:57 +0000

application.ini and platform.ini are required outside of the app – l10n uses them to correctly process repacks and for other reasons. You’ll need to provide the info somewhere else if you compile it in. You also can’t compile application.ini in afaik as that is the main config part of a xulrunner app.

If you remove the stat check on the components you’ll break the majority of developers – many devs use the fact these are symlinked (on mac & linux) and can change the code without even recompiling. Removing this would break devs significantly. Also I think Thunderbird doesn’t even use .autoreg at the moment as Benjamin said it wasn’t necessary.

You’re also conflicting yourself. You said you’ll check for a .manifest inside the .jar after checking alongside the .jar. That would be a wasted stat in most cases.

There’s a similar developer issue with extensions/ – dev through extensions may start to be more popular. Additionally, if someone installs an extension globally, they’ll have to update the .autoreg file to get it to be picked up – that doesn’t sound like something most people would know to do.

Prefs – don’t forget about the possibility of a user.js or even other .js files (I think MCD has some).

Please also remember to notify comm-central/other apps of these changes or at least keep a live list of what has changed wrt startup. It will make it much easier for us to pick these changes up and we may then be able to do it at the same time as you land or before if appropriate – it saves us firefighting time.

By: glandium

glandium — Fri, 21 Aug 2009 07:22:37 +0000

> Perhaps, instead of reading these files should be compiling this info into the xulrunner launcher app?

Please don’t. That would make using the plain xulrunner stub impossible.

> For some reason only one of my computers is reading the spellcheck dictionary at startup, but it is costing me 70ms. I wonder if these can be moved to a locale jar

Please don’t. Or at least, still allow for the spellcheck dictionaries to be files in a system-wide directory, shared with OOo (which is done on Linux distros). Please avoid requiring patches to libhunspell, too, so that system-wide libhunspell can still be used.

By: Zack

Zack — Fri, 21 Aug 2009 05:59:18 +0000

Should we maybe be running the JS files through a minimizer and the XML files at least through a comment stripper? At build time, I mean.

By: pd

pd — Fri, 21 Aug 2009 04:21:50 +0000

looking at this from the perspective of a complete outsider, is there a reason that so much data has to be stored in files and in separate files at that?

Has anyone considered throwing a lot more into SQLite database files? For example preferences? Would this be any faster?

It seems it took a lot of time to build Places into the codebase and perhaps that is still not perfect (awesome bar perf lags with too much history to churn through?). Would a similar level of resources be required to move a lot of file data to SQLite database files?

By: Justin Dolske

Justin Dolske — Fri, 21 Aug 2009 01:36:18 +0000

The default16.png stuff is coming from nsWindow::SetIcon(). Are there multiple windows (hidden window?)? Or maybe we’re just dumb and call it from few different places.

By: Dan

Dan — Fri, 21 Aug 2009 00:58:38 +0000

“I haven’t touched the stuff in the profile directories or libraries.” I assume that there are similar wins to be found in profile loading, and perhaps smaller wins in library loading?