* TITLE/SUMMARY [PP] Mac Apprunner loads 2X slower than Win32 Apprunner * GENERAL FOO Here are some comparisons of the loading time for Mac Apprunner (4.13.99 M4 build), starting from when the application icon double-click is complete, and ending at the point in which the "Welcome to the Gecko Browser" text appears. In the case of Communicator, I ended it after the Netcenter page begun to display. [I've also lowered the cache on the Mac to the minimum of 128K, too, and restarted Windows prior to the first launch of each application, since Win NT tends to load apps much faster the second time than the first time.] MACINTOSH: - Communicator 4.51: 18 seconds - Apprunner: 32 seconds - Apprunner (with registry deleted): 47 seconds WINDOWS: - Communicator 4.51: 12 seconds - Apprunner: 14 seconds - Apprunner (with registry deleted): 21 seconds [#Thanks to Simon, for pointing out the scenario of launching without a registry.] * CONFIGURATIONS TESTED - [Mac] Power Mac 8500/120 (233 Mhz 604e), 64 MB RAM (VM on; 1 MB of VM used), 1024x768 (Thousands of Colors), Mac OS 8.5.1 - [Win32] Vectra VL (233 Mhz P2), 96 MB RAM, 800x600 (True Color), NT 4.0 SP3. - [Linux] Vectra VL (266 Mhz P2), 96 MB RAM.

[Please note specifically that the issue I'm raising is that --- on the same system --- Apprunner is taking almost twice as long to load as the full Communicator 4.5 suite, whereas on Windows, the load time is roughly equivalent.]

Not sure why this is on don's list. I'm adding dveditz cuz he can probably shed light on the XP_FileFlush call in modules/libreg/src/reg.c added long ago (it's a macro that calls PR_Sync, see news://news.mozilla.org/3714E890.1F849C39@netscape.com and sequelae). If this was a workaround for Mac NSPR not supporting PR_SYNC, then it seems to me it should have been #ifdef XP_MAC, or something. Better yet, get NSPR fixed, or at least aware of the bug (wtc seems to have found out only now). Don't hack i/o to be synchronous and move on. (Who the heck am I preaching to here, anyway? Probably only the choir.) /be

[Assigned to Don since he was the default for Apprunner, and I didn't know any better. Pleas reassign as you desire. Thanks!]

On 04/23 we will have regular weekly reports on Page Load Metrics. elig, check out the results that come out that day or Monday and let's see if there is improvement.

This refers to startup, rather than page loading. Pink, what was the outcome of the PR_Synch stuff you looked at?

I could not find any reference to PR_Sync in the libreg code that I patched up for MacOS. Looks like i didn't accidentally check that line in after all. It has gotten MUCH slower in the past few days, I've noticed. Wonder why.

Offloading some of gordon's doomage

Shouldn't we be measuring this with a default Mac cache on a target machine?

Neither gordon or I could figure out what the intention of reducing the cache size was when we were reviewing this one. I'll be talking to elig about it soon.

[I lowered the cache to 128K because most 8.1 users I've seen who aren't technically savvy tend to leave their cache at the default setting, which I recall to be around 128K. I've dropped a line to the most recent quality lead for the Memory control panel at Apple to confirm or deny this. Peter indicates that 8.5 is the primary platform of concern, so I'll go ahead and retest this within one business day using a default 8.5 cache of 2MB (at least, default for a 2 Gig HD w/64 MB RAM), and append the results.]

(2.26.99 build, on the same 233 Mhz 604e Mac OS system, but using a 2 MB cache instead of a 128K cache.) MACINTOSH: - Communicator 4.51: 15 seconds - Apprunner: 37 seconds - Apprunner (with registry deleted): 57 seconds I believe that one can abstract from the above that Seamonkey for Mac OS now launches at least 20% more slowly than it did two weeks before.

[Duh, obviously, I meant 4.26.99 build.]

NSPR now has its own Bugzilla product. Moving this bug to the NSPR product.

This isn't an NSPR bug. Moving back to the browser product.

Is there a different bug for the NSPR bustage that's requiring PR_Sync() on the Mac? That needs to get fixed before we remove the PR_Sync() call from Mozilla

[Just FYI, the 4.30.99 Mac OS build now requires *58* seconds to launch with pre- existing registry, same settings as 4.26.99 comment.]

[Per request from the Dr. Fraser, it takes 106 seconds to load Seamonkey with the registry blown away; same configuration.]

The various registry problems (this, and bug 3690) strongly suggest to me that we need to take a close look at the registry process, and ask ourselves whether it needs serious redesign. I'm marking this M6, P2 in the hope that we can get a big push for registry fixes in by M6.

Bug 4965 is another registry problem which needs serious thought.

sliding into M7 so it's not an M6 blocker (and we'll probably be tweaking performance forwver)

Eli, what's the current startup times you're seeing (as of the 5/19 build)? I justed checked in an NSPR tweak and I'm curious if it makes a noticable difference on your system (it was about a 2 second improvment in startup time on my Mac).

Using 5.19.99 Mac OS build: 1. No pre-existing registry: 98 seconds (just to reach new profile wizard) 2. Pre-existing registry: 24 seconds (just to reach new profile wizard) Using 5.19.99 Win NT build: 1. No pre-existing registry: 16 seconds (just to reach new profile wizard) 2. Pre-existing registry: 4 seconds This makes me even happier to know that I'm going on vacation today...

Per Steve dagley's cube visit: * 5.19.99 build on Mac OS takes :34 seconds with a registry to launch (after user profile creation launch; didn't realize the crash had a workaround...) * 5.18.99 PM builds on Mac OS: 1. No pre-existing registry: 105 seconds 2. Pre-existing registry: 47 seconds So, it's faster...but there's still a huge 4:1 disparity between the Win32 and Mac OS launch performance, whereas there was only a 1.3:1 disparity in 4.51.

Moving all Apprunner bugs past and present to Other component temporarily whilst don and I set correct component. Apprunner component will be deleted/retired shortly.

upgrading to blocker severity. beta blocker.

since the component registry seems to have been fingered as the culprit here I'm re-assigning this one to dp

I'm working on this one already under another number, at least the registry specific parts.

So what if we were to change the registry so that it didn't WriteFile every time it set a string value, and instead wrote to (and read from) an in-memory buffer that it could flush later? Or is most of the pain here that we're doing syncing all the time? What's the other bug you mention, so I can keep up to date?

Syncing isn't the problem--I removed that call a long time ago (see 8745) and people are still complaining. Reading and writing to a buffer is exactly what I had in mind. NSPR supports memory-mapped I/O, but not on a Mac of course.

New registry buffering code should help this quite a bit. We can play with the buffer size some, but I know Mac's are memory sensitive so didn't want to make it too big.

Using a 233 Mhz P2 and a 266 G3 (beige, 64 MB RAM), and launching only with an existing profile, here were the ranges for 3 attempts: Mac OS: 22-24 seconds (Apprunner) 9 seconds (Communicator 4.7) [e.g. Apprunner takes 2.5x as long as Communicator 4.7 to launch] Win32: 15-18 seconds (Apprunner) 12 seconds (Communicator 4.7) [e.g. Apprunner takes about ~1.4 as long as Communicator to launch.] So, while no longer 2X slower than on Win32 compared to 4.x, they're still not at parity. I punt a decision to one of the Time Bandits.

Using a 233 Mhz P2 and a 266 G3 (beige, 64 MB RAM), and launching only with an existing profile, here were the ranges for 3 attempts: Mac OS: 22-24 seconds (Apprunner) 9 seconds (Communicator 4.7) [e.g. Apprunner takes 2.5x as long as Communicator 4.7 to launch] Win32: 15-18 seconds (Apprunner) 12 seconds (Communicator 4.7) [e.g. Apprunner takes about ~1.4 as long as Communicator to launch.] So, while no longer 2X slower than on Win32 compared to 4.x, they're still not at parity. I punt a decision to one of the Time Bandits.

Not fast enough! Reopening.

I'll take this for now.

Forgot to add: * Systems were restarted in between each performance tests to bypass OS optimization of relaunches. * Disk Cache was set for 3 MB on the Mac.

Putting on [PDT+] radar.

On-going performance work, won't be done by M11.

2x is our dogfood goal, but the re-launch time is now 3x worse than Win32.

Could you add some startup performance numbers, and machine config in this bug? Thanks.

Removed PDT+ to get some reconsideration at the PDT meeting. I just watched a startup for last week's build. On a believably fast machine (belonging to Waterson), it took 4.1 seconds to startup. In constrast, a 4.x build took a whopping 2.9 seconds. Bottom line: Even if this specific machine is "fast," this level of speed in *startup* should not be a dogfood stopper IMO.

but i believe, and we need some numbers here, that on slow machines it's like 10 seconds vs 20 seconds. that's a big deal.

I checked the back of waterson's Mac, and it's a 400 Mhz Yosemite G3. For non-Mac geeks, this Mac's performance is within roughly 10-15% of the fastest Macintosh money can buy, and was top-of-the-line a few months ago. Launching the yesterday's build on a 266 Mhz beige G3, I experience a 12 second launch time (with a 7 second re-launch time, if the Mac hasn't restarted between launches.) This 266 Mhz G3 Mac was top-of-the-line-ish about 20-22 months ago, and may be a more reasonable target.

All agree, a PDT- at this time.

since this is a tracking bug, I'm moving this over to where the other tracking bugs have been placed (M20). I realize there are dependencies on this bug, but we need to move it out for now.

removing PDT+ tracking bug dependency

removing PDT- from status whiteboard

Putting on [BETA]radar.

Why is this bug marked as OS FreeBSD ? It should be Mac System 8.5, no ?

Fix OS version setting

Bulk add of "perf" to new keyword field. This will replace the [PERF] we were using in the Status Summary field.

removing vestigial tags, putting on beta1 radar per beta criteria priority #2

BTW, on my very target-like 200Mhz PB3400, it takes 23 seconds do a secondary launch and load of about:blank. 4.7 takes 11 seconds.

Hmm. Is it normal that I can change Priority, assigned to, etc ?

[E-mailed gozer@hbe.ca CC:ing terry@mozilla.org to explain Bugzilla 101.]

This is _strange_ and is it me or it shouldn't happen ? I installed bugzilla on our system and someone complained about people being able to change all the information about a bug . I didn't believe it, so I tried it on a random mozilla.org bug, just to see if we had a misconfiguration. Apparently not.

Fixing gozer's damage. PLEASE DO NOT TOUCH THIS BUG AGAIN!! Setting Priority back to 2 per trudelle comment, back to Browser, Mac, Blocker, Dom Level 1.

Jan: is this not the kind of what we were talking about with Mitchell? How much time have you, Eli, terry and whoever spent on this one person's "test". Imagine if it were a test of the "change many bugs at once" feature.

STOP WHINING IN THIS BUG! If you want to complain about Bugzilla, do it in an appropriate forum. FYI, this kind of damage seems to happen about once a month. I generally repair it.

remove beta1 keyword

Downgrading severity from blocker, marking M16. I'm still looking at this.

moving out to M17 where perf work will be done

Adding nsbeta3 keyword to get on plus radar during that triaging in the future if needed. We will need the latest perf page load test results after beta2. Setting myself as QA Contact.

moving to m18

tracking -- m20

FWIW -- this is a tracking bug for Simon, I would rather not put the nsbeta3+ marker on this because it will be open well past nsbeta3 -- Jan, would you mind if I removed the nsbeta3 keyword

no problem

updating keywords

PR3 feedback: I must say i´m not impressed, Ns3 takes about 10-12 seconds to start on my G3 333mhz mac (os9.0.4) and Internet Explorer t akes about 1-2,5 seconds to start. After the EXTREMELY slow startup its quite ok, but i and probably not many others will want to have a browser that takes a year or two to startup. I don´t care so much about bugs, its all launch speed i want. Are you guys planning to do something about that or ? Please throw me a bone, are youi going to speed optimize the browser or i cant get why you would release a not optimized browser at first, but you abviously did ????!?!?!?!?!?

Mozilla0.9

leger is no longer @netscape.com changing qa contact to default for this component

nominating for nsbeta1

reassign to chofmann, can you please assign this to the appropriate person on your team

thesteve might be able to help analyze this but we are mostly focused on embedded components not seamonkey, and then working on performance analysis on win32, linux, and then mac in those rough priority orders. jrgm found some recent interesting data on pageloading and the cache. (turn it off and we go much faster on mac. If someone can give thesteve a brain dump he might be able to think about how we can do some analysis and turn up some things to fix... we should also think about closing this bug and starting fresh without all the noise and baggage

Adding sdagley to the CC. Steve, is this on your list of things to worry about for the Mac in 6.5?

Since I've been tasked with looking at startup performace on the mac for next release, I guess I'll take this bug

Moving to mozilla0.9.1

nav triage team: Marking future

wrong answer. how about some reasons before you do this?

nav triage team: Here you go: 1) This bug is REALLY old 2) Is mac mozilla currentl 2x slower than win32? 3) We've had lots of folks looking at performance, and we've come a long and still have further to go 4) This bug is too general, and one could conceivably keep it open until the heat death of the universe

This bug and bug 28855 are the same (startup on Mac is slow). Neither bug is tracking any specific code-level problems that make Mozilla slower on Mac than it is on Windows. We also have bug 7251 tracking startup performance problems on all platforms.

*** This bug has been marked as a duplicate of 28855 ***

vrfy