Closed Bug 5085 Opened 25 years ago Closed 23 years ago

Mac Apprunner loads 2X slower than Win32 Apprunner

Categories

(SeaMonkey :: General, defect, P2)

Product:
SeaMonkey
Component:
General
Platform:
PowerPC
Mac System 8.6
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 28855
Milestone:
Future

People

(Reporter: elig, Assigned: paulkchen)

References

Details

(Keywords: meta, perf, platform-parity) 

* 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.
Whiteboard: [Perf]
[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!]
Assignee: don → srinivas
Component: Apprunner → NSPR
QA Contact: 3853 → 1698
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.
Assignee: srinivas → gordon
Assignee: gordon → sdagley
Offloading some of gordon's doomage
Shouldn't we be measuring this with a default Mac cache on a target machine?
Status: NEW → ASSIGNED
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.
Component: NSPR → Apprunner
Product: NSPR → Browser
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.]
Status: ASSIGNED → NEW
Priority: P3 → P2
Target Milestone: M6
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.
Status: NEW → ASSIGNED
Target Milestone: M6 → M7
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.
Target Milestone: M7 → M8
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.
Depends on: 8745
Target Milestone: M8 → M10
Blocks: 7251
Target Milestone: M10 → M11
Blocks: 12671
Blocks: 12659
Severity: major → blocker
upgrading to blocker severity. beta blocker.
Assignee: sdagley → dp
Status: ASSIGNED → NEW
since the component registry seems to have been fingered as the culprit here I'm
re-assigning this one to dp
Assignee: dp → dveditz
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.
Status: NEW → RESOLVED
Closed: 25 years ago
Component: other → DOM Level 1
OS: Mac System 8.5 → FreeBSD
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.
Blocks: 14469
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.
Status: RESOLVED → REOPENED
Assignee: dveditz → sfraser
Status: REOPENED → NEW
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.
Depends on: 15726
Whiteboard: [Perf] → [PDT+][Perf]
Putting on [PDT+] radar.
Blocks: 12658
Blocks: 17432
Priority: P2 → P1
Summary: [PP] Mac Apprunner loads 2X slower than Win32 Apprunner → [DOGFOOD][PP] Mac Apprunner loads 2X slower than Win32 Apprunner
Status: NEW → ASSIGNED
Target Milestone: M11 → M12
On-going performance work, won't be done by M11.
Blocks: 17907
Blocks: 18471
Whiteboard: [PDT+][Perf] → [PDT+][on-going till RTM][Perf]
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.
Whiteboard: [PDT+][on-going till RTM][Perf] → [on-going till RTM][Perf]
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.
Whiteboard: [on-going till RTM][Perf] → [PDT-][on-going till RTM][Perf]
All agree, a PDT- at this time.
Target Milestone: M12 → M20
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.
No longer blocks: 12658
removing PDT+ tracking bug dependency
Blocks: 20870
Whiteboard: [PDT-][on-going till RTM][Perf] → [on-going till RTM][Perf]
removing PDT- from status whiteboard
Summary: [DOGFOOD][PP] Mac Apprunner loads 2X slower than Win32 Apprunner → [BETA][PP] Mac Apprunner loads 2X slower than Win32 Apprunner
Putting on [BETA]radar.
Why is this bug marked as OS FreeBSD ? It should be Mac System 8.5, no ?
OS: FreeBSD → Mac System 8.5
Fix OS version setting
Keywords: perf
Bulk add of "perf" to new keyword field.  This will replace the [PERF] we were
using in the Status Summary field.
Keywords: pp
removing vestigial tags, putting on beta1 radar per beta criteria priority #2
Keywords: beta1
Summary: [BETA][PP] Mac Apprunner loads 2X slower than Win32 Apprunner → Mac Apprunner loads 2X slower than Win32 Apprunner
Whiteboard: [on-going till RTM][Perf] → [on-going till RTM]
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.
Severity: blocker → normal
Component: DOM Level 1 → Preferencecs
OS: Mac System 8.5 → HP-UX
Priority: P1 → P4
Product: Browser → Grendel
Hmm. Is it normal that I can change Priority, assigned to, etc ?
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → WONTFIX
[E-mailed gozer@hbe.ca CC:ing terry@mozilla.org to explain Bugzilla 101.]
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
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.
Status: REOPENED → CLOSED
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.
Severity: normal → blocker
Status: CLOSED → REOPENED
Component: Preferencecs → DOM Level 1
OS: HP-UX → Mac System 8.6
Priority: P4 → P2
Product: Grendel → Browser
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
Keywords: beta1
Downgrading severity from blocker, marking M16. I'm still looking at this.
Severity: blocker → critical
Status: REOPENED → ASSIGNED
Target Milestone: M20 → M16
moving out to M17 where perf work will be done
Target Milestone: M16 → M17
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.
Keywords: nsbeta3
QA Contact: elig → leger
No longer blocks: 17432
No longer blocks: 17907
No longer blocks: 18471
No longer blocks: 20870
moving to m18
Component: DOM Level 1 → Browser-General
Target Milestone: M17 → M18
tracking -- m20
Target Milestone: M18 → 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
Keywords: nsbeta3
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
Whiteboard: [on-going till RTM]
Target Milestone: M20 → mozilla0.9
leger is no longer @netscape.com
changing qa contact to default for this component
QA Contact: leger → doronr
nominating for nsbeta1
Keywords: mozilla0.9, nsbeta1
reassign to chofmann, can you please assign this to the appropriate person on 
your team
Assignee: sfraser → chofmann
Status: ASSIGNED → NEW
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
Assignee: chofmann → thesteve
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
Assignee: thesteve → pchen
Keywords: nsbeta1 → meta
Moving to mozilla0.9.1
Target Milestone: mozilla0.9 → mozilla0.9.1
nav triage team:

Marking future
Target Milestone: mozilla0.9.1 → Future
wrong answer. how about some reasons before you do this?
Target Milestone: Future → ---
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
Keywords: nsbeta1-
Target Milestone: --- → Future
No longer blocks: 7251
Blocks: 7251
No longer blocks: 7251
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 ***
Status: NEW → RESOLVED
Closed: 25 years ago → 23 years ago
Resolution: --- → DUPLICATE
vrfy
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.