Mac Apprunner loads 2X slower than Win32 Apprunner

VERIFIED DUPLICATE of bug 28855

Status

defect
P2
critical
VERIFIED DUPLICATE of bug 28855
21 years ago
15 years ago

People

(Reporter: elig, Assigned: paulkchen)

Tracking

({meta, perf, platform-parity})

Trunk
Future
PowerPC
Mac System 8.6
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Reporter

Description

21 years ago
* 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.
Reporter

Updated

21 years ago
Whiteboard: [Perf]
Reporter

Comment 1

21 years ago
[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.]

Comment 2

21 years ago
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
Reporter

Comment 3

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

Updated

21 years ago
Assignee: don → srinivas
Component: Apprunner → NSPR
QA Contact: 3853 → 1698

Comment 4

21 years ago
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.

Updated

21 years ago
Assignee: srinivas → gordon

Updated

21 years ago
Assignee: gordon → sdagley

Comment 7

21 years ago
Offloading some of gordon's doomage

Comment 8

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

Updated

21 years ago
Status: NEW → ASSIGNED

Comment 9

21 years ago
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.
Reporter

Comment 10

21 years ago
[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.]
Reporter

Comment 11

21 years ago
(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.
Reporter

Comment 12

21 years ago
[Duh, obviously, I meant 4.26.99 build.]

Comment 13

20 years ago
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
Reporter

Comment 16

20 years ago
[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.]
Reporter

Comment 17

20 years ago
[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.

Updated

20 years ago
Status: NEW → ASSIGNED
Target Milestone: M6 → M7

Comment 20

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

Comment 21

20 years ago
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).
Reporter

Comment 22

20 years ago
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...
Reporter

Comment 23

20 years ago
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.

Updated

20 years ago
Target Milestone: M7 → M8

Comment 24

20 years ago
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

Updated

20 years ago
Target Milestone: M8 → M10

Updated

20 years ago
Blocks: 7251

Updated

20 years ago
Target Milestone: M10 → M11

Updated

20 years ago
Blocks: 12671
Blocks: 12659
Severity: major → blocker
upgrading to blocker severity. beta blocker.

Updated

20 years ago
Assignee: sdagley → dp
Status: ASSIGNED → NEW

Comment 26

20 years ago
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: 20 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.

Updated

20 years ago
Blocks: 14469
Reporter

Comment 31

20 years ago
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.
Reporter

Comment 32

20 years ago
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.
Reporter

Comment 35

20 years ago
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.

Updated

20 years ago
Depends on: 15726

Updated

20 years ago
Whiteboard: [Perf] → [PDT+][Perf]

Comment 36

20 years ago
Putting on [PDT+] radar.

Updated

20 years ago
Blocks: 12658

Updated

20 years ago
Blocks: 17432

Updated

20 years ago
Priority: P2 → P1

Updated

20 years ago
Summary: [PP] Mac Apprunner loads 2X slower than Win32 Apprunner → [DOGFOOD][PP] Mac Apprunner loads 2X slower than Win32 Apprunner

Updated

20 years ago
Status: NEW → ASSIGNED
Target Milestone: M11 → M12
On-going performance work, won't be done by M11.

Updated

20 years ago
Blocks: 17907

Updated

20 years ago
Blocks: 18471

Updated

20 years ago
Whiteboard: [PDT+][Perf] → [PDT+][on-going till RTM][Perf]

Comment 38

20 years ago
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.

Updated

20 years ago
Whiteboard: [PDT+][on-going till RTM][Perf] → [on-going till RTM][Perf]

Comment 40

20 years ago
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.
Reporter

Comment 42

20 years ago
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.

Updated

20 years ago
Whiteboard: [on-going till RTM][Perf] → [PDT-][on-going till RTM][Perf]

Comment 43

20 years ago
All agree, a PDT- at this time.

Updated

20 years ago
Target Milestone: M12 → M20

Comment 44

20 years ago
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.

Updated

20 years ago
No longer blocks: 12658

Comment 45

20 years ago
removing PDT+ tracking bug dependency

Updated

20 years ago
Blocks: 20870

Updated

20 years ago
Whiteboard: [PDT-][on-going till RTM][Perf] → [on-going till RTM][Perf]

Comment 46

20 years ago
removing PDT- from status whiteboard

Updated

20 years ago
Summary: [DOGFOOD][PP] Mac Apprunner loads 2X slower than Win32 Apprunner → [BETA][PP] Mac Apprunner loads 2X slower than Win32 Apprunner

Comment 47

20 years ago
Putting on [BETA]radar.

Comment 48

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

Updated

20 years ago
OS: FreeBSD → Mac System 8.5

Comment 49

20 years ago
Fix OS version setting

Updated

20 years ago
Keywords: perf

Comment 50

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

Updated

20 years ago
Keywords: pp

Comment 51

20 years ago
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]

Comment 52

20 years ago
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.

Updated

20 years ago
Severity: blocker → normal
Component: DOM Level 1 → Preferencecs
OS: Mac System 8.5 → HP-UX
Priority: P1 → P4
Product: Browser → Grendel

Comment 53

20 years ago
Hmm. Is it normal that I can change Priority, assigned to, etc ?
Status: ASSIGNED → RESOLVED
Closed: 20 years ago20 years ago
Resolution: --- → WONTFIX
Reporter

Comment 54

20 years ago
[E-mailed gozer@hbe.ca CC:ing terry@mozilla.org to explain Bugzilla 101.]
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---

Comment 55

20 years ago
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

Comment 56

20 years ago
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.

Comment 58

20 years ago
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.

Comment 59

20 years ago
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

Comment 61

20 years ago
moving out to M17 where perf work will be done
Target Milestone: M16 → M17

Comment 62

19 years ago
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

Updated

19 years ago
No longer blocks: 17432

Updated

19 years ago
No longer blocks: 17907

Updated

19 years ago
No longer blocks: 18471

Updated

19 years ago
No longer blocks: 20870

Comment 63

19 years ago
moving to m18
Component: DOM Level 1 → Browser-General
Target Milestone: M17 → M18

Comment 64

19 years ago
tracking -- m20
Target Milestone: M18 → M20

Comment 65

19 years ago
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

Comment 66

19 years ago
no problem

Comment 67

19 years ago
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

Comment 70

19 years ago
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

Comment 72

19 years ago
reassign to chofmann, can you please assign this to the appropriate person on 
your team
Assignee: sfraser → chofmann
Status: ASSIGNED → NEW

Comment 73

19 years ago
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

Comment 74

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

Comment 75

19 years ago
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: nsbeta1meta
Assignee

Comment 76

18 years ago
Moving to mozilla0.9.1
Target Milestone: mozilla0.9 → mozilla0.9.1
Assignee

Comment 77

18 years ago
nav triage team:

Marking future
Target Milestone: mozilla0.9.1 → Future
wrong answer. how about some reasons before you do this?
Target Milestone: Future → ---
Assignee

Comment 79

18 years ago
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

Updated

18 years ago
Blocks: 7251

Updated

18 years ago
No longer blocks: 7251

Comment 80

18 years ago
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.

Comment 81

18 years ago

*** This bug has been marked as a duplicate of 28855 ***
Status: NEW → RESOLVED
Closed: 20 years ago18 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.