Need to yield time to other applications during startup

RESOLVED WONTFIX

Status

defect
P4
normal
RESOLVED WONTFIX
19 years ago
15 years ago

People

(Reporter: sfraser_bugs, Assigned: beard)

Tracking

({perf})

Trunk
Future
PowerPC
Mac System 8.5
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Mozilla hogging the CPU during startup on Mac was identified as one of the issues 
for Mac dogfood. We need to figure out how to make it play nice with other apps 
during startup (more WaitNextEvent calls). This could be done:

* Get to the main event loop earlier, or...
* Sprinkle yield calls around in startup code (maybe use progress callbacks)
* Spawn a 2nd NSPR thread which parasitically calls WaitNextEvent
Keywords: nsbeta3, nsmac1, perf
I don't get this, most Mac apps just take over your machine 100% while they're 
launching. I was actually shocked that I could do anything at all while Moz was 
starting up! 

Maybe someone will disagree but I think Mozilla is already better at this than 
any other Mac app I can think of. Then again, I have a G4 so performance is not 
something I can judge.

I think this is good enough. Naturally it would be nicer if Moz started *faster* 
but that would almost argue the other way - towards calling waitnextevent less!
Are you running debug or optimized builds?
Nightlies, so optimised.

I can definately interact with the Finder and other apps while Mozilla is 
loading.
Updating to beta3+.
Status: NEW → ASSIGNED
Priority: P3 → P2
Whiteboard: [nsbeta3+]
PDT feels that faster startup is most critical.  Given potential risk to our 
stability at this point, we'd rather see the app go out "not playing nice" 
during startup (hopefully, an event that does not dominate usage).
Moving to P4
Priority: P2 → P4
Whiteboard: [nsbeta3+] → [nsbeta3+][PDTP4]
per PDT: P3-P5 priority bugs changed from nsbeta3+ to nsbeta3- since we have
more important work to do for Seamonkey. If you disagree, please state your case
in the bug report and nominate for rtm. Thanks.
Whiteboard: [nsbeta3+][PDTP4] → [nsbeta3-][PDTP4]
I think sfraser's original report is a reasonable nomination for rtm.
Keywords: rtm
Target Milestone: --- → Future
rtm-, already noted in the bug that this isn't worth doing right now.
Whiteboard: [nsbeta3-][PDTP4] → [nsbeta3-][PDTP4][rtm-]
Blocks: 7251
No longer blocks: 7251
Blocks: 7251
Removing adequated PDT grafitti.  
Whiteboard: [nsbeta3-][PDTP4][rtm-]
Keywords: nsbeta3
This bug is targeted at a Mac classic platform/OS, which is no longer supported
by mozilla.org. Please re-target it to another platform/OS if this bug applies
there as well or resolve this bug.

I will resolve this bug as WONTFIX in four weeks if no action has been taken.
To filter this and similar messages out, please filter for "mac_cla_reorg".
Not applicable on OS X.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → WONTFIX
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.