486408 - Firefox "Applications" preference pane is really slow to load; does 2x the work it realy needs to; blocks UI thread on disk access

Status: NEW

(Firefox :: Settings UI, defect)

Description

[Boris Zbarsky [:bzbarsky]]

Over here, opening the "Applications" pane of preferences takes about 1.5-2 seconds in a nightly build; during this time the browser is unresponsive and the disk is thrashing.  Subsequent attempts to open it are faster (make sure to close the preferences dialog in between tests, since it caches the overlay), but still noticeably slow (order of 0.5 seconds or more).  I have a pretty fast machine, so it's got to be slower elsewhere...

I profiled this, and it looks like the time is split about as follows:

33% nsOSHelperAppService::GetFromTypeAndExtension, called directly from JS.
    This time is spent about 2/3 under
    nsInternetConfigService::GetMappingForMIMEType and 1/3 under
    nsInternetConfigService:FillMIMEInfo.
25% nsImageBoxFrame::Init doing an AsyncOpen on nsIconChannel.  This time is
    all spent under ... nsOSHelperAppService::GetFromTypeAndExtension.
10% Style resolution and the like during frame construction.
5%  NSImage stuff that nsIconChannel::OpenInputStream is doing (locking and
    unocking focus, iconForFileType, etc).
7%  sorting JS arrays
10% kernel memory management (vm_fault, mmap, etc; we must be thrashing memory
   hard somewhere here).

I seem to have about 70-80 MIME types listed here in a newly-created profile; almost all are from the quicktime plug-in.  This is hardly an uncommon setup.

It would be really nice to not have to get MIME info twice here; once we get it, can we not just put whatever info the icon channel needs in the icon url?  It would also be really nice to not go through all that icon stuff in cases when it won't help; not sure how to detect those easily, though.  I'm not sure all the icon loading really needs to happen synchronously from opening the dialog (or even on the main thread?  Could the icon channel get the data async on a background thread?).

Please file dependent bugs on specific things to fix as needed, of course.