I installed M12 on my mac using the installer...I don't think I'll do it ever again. Installing took exactly 46 minutes (!), with no possibility to cancel (see Bug 22194), blocking my whole computer, with no possibility to switch between open apps. Installing using the self-extracting StuffIt-archive was much faster. I'm using a Mac with a 603e - 120MHz processor, 35 Megs of RAM (24 Megs are phisical).

reassign to Samir. Grace, can you help and see if we can reproduce this problem in house?

Cathleen, I downloaded and installed the M12 release on 3 machines: My G3, 64k Ram, OS 8.5 6 minutes 225mhz, 604e,128k Ram, OS 8.5.1 25 minutes 233mhz, 64k Ram 23 minutes I expect doing this over modem could slow it down further.

Changing summary to reflect this is a performance issue.

This speed is not acceptable for beta. With the miminal requirement machines, this could possibly be a lot worse.

Samir, how fast or slow comparatively is the "manyfiles" install? Is it the number of files that slows us down, or the extracting of large files? Manyfiles would be easier to profile if it's also slow because it wouldn't overwrite the version you're trying to profile. It would also tend to get the zip code off the hook. You could also try commenting out the dialog updates (notifier calls) in nsXPInstallManager to see if it's the synchronous calls to the UI thread that's killing us. I think we need to batch dialog updates based on a timer or something anyway, but it'd be interesting to see if that's part of *this* problem or just incidental.

Never mind most of that... Obviously it's not the XUL UI slowing us down if this is being run from the native install wizard.

Actually Dan, your comments will be useful when I profile the engine because I believe it is slow to update from the browser as well.

Profiling the Mac Install Wizard and its use of the XPInstall Engine revealed that with a Netscape Registry of 4MB 77.3% of the time was spent in RegisterInVersionRegistry() of nsInstallFile::Complete() (the Finalize phase). (Time = ~440,000) Dan and I analyzed the call tree further and found that most of the time was spent in doing file i/o from the registry code (specifcally under nr_Find()). Whacking the registry helped shave the install time to half the originally observed time with the 4MB Netscape Registry. (Time = ~285,000) Further, increasing the registry buffer from 64K to 1MB shaved the time to ~1/3 the originally observed time with the 4MB Netscape Registry and perceived progress appeared almost acceptable on the Mac (wizard). (Time = ~136,000) Given that the performance improvements depend heavily on registry buffer implementation improvements I am reassigning this bug to Dan per his request. I'll work on seeing if we can improve the AppleSingle decoding performance.

Putting on PDT+ radar for beta1.

Making pdt+ bugs P1

For this release I'll go for the quick fix of expanding the buffer during XPInstall, eating up memory. After beta we will reformat what data we actually store and perhaps how we store it.

Fix checked in. This gets the registry slowness which was about 80% of the time spent. There may also be some AppleSingle improvements in the works that will help with the remaining time.

wow- build 2000022308