Closed Bug 76705 Opened 19 years ago Closed 14 years ago

application-level improvements to startup

Categories

(SeaMonkey :: General, defect, P1)

defect

Tracking

(Not tracked)

RESOLVED FIXED
mozilla1.2alpha

People

(Reporter: waterson, Assigned: trudelle)

References

Details

(Keywords: meta, perf, topperf, Whiteboard: [nav+perf])

Attachments

(5 files)

Placeholder bug to track application-level (i.e., XUL, JS, CSS) improvements 
that affect startup time. Filed to vishy per his request.

>> waterson's  "skinny-dip theme" has launch and relaunch times that
>> rival 4.x startup...
>>
>>                     win98
>>                    launch  re-lauch
>> Communicator 4.76  10.09  1.88
>> skinny dip         11.64  2.93
Keywords: perf
Attached file the skinny dip theme
To generate startup time numbers using ``the skinny dip theme'', save the above 
attachment; e.g., in c:\tmp, and do

  mozilla -chrome file:///c:/tmp/minimal.xul

Need to investigate this in the m0.9.1 timeframe. 
adding topperf.  startup is still our sore thumb..
Keywords: topperf
I think new-window is our sore thumb. I'm eating donuts during startup anyway.
if the *first* new window gets faster do the subsquent new windows get faster?
I each a donut for each new window that opens.
> if the *first* new window gets faster do the subsquent new windows get faster?

(I'm assuming that by ``first new window'', you mean ``the first window 
displayed when the browser starts.'')

The answer is ``not necessarily''. In measuring app startup, we're measuring

1. bootstrap time (including XPCOM, chrome registry, ...)

2. uncached browser window creation time (including reading XUL, JS, XBL
   and CSS from JAR files, then compiling them)

3. window display time

If we measure the time it takes to create the *second* browser window, we'll 
measure:

1. cached browser window creation time (XUL & JS are brutally shared from
   cache: no recompilation or parsing needed; XBL is re-initialized from
   cached: no round-trip to JAR file needed; CSS is brutally shared from
   cache.)
   
2. window display time

That said, reducing the amount of XUL/JS/XBL/CSS we've got to deal with (either 
load+compile, or brutally sharing) helps all around.

So, I guess what I'd recommend is that the apps team should focus on 
streamlining the XUL, JS, XBL, and CSS. The toolkit team should focus on 
improving the efficiency of XUL/JS/XBL/CSS brutal sharing.
I wonder how Joe's stylesheet scoping will help here...
OS: Windows 2000 → All
Hardware: PC → All
I haven't taken any empirical measurements of startup/new window time with the
stylesheet scoping on, but I can't perceive any significant gains with my mental
stopwatch.
Blocks: 7251
Priority: -- → P1
Target Milestone: --- → mozilla0.9.1
hi vishy, this bug is on your plate for almost 2 weeks.  if you're too busy to 
drive it... lets figure out and reassign to someone to drive this today.  :-)
nav triage: yes this needs to be done for mozilla0.9.1.
Keywords: nsbeta1nsbeta1+
Priority: P1 → P2
I can take this if you want for profiling, comments, xpapps suggestions and the 
like, but it's unclear to me what more (if anything) this bug is asking for.
I have done some special profiling work last 2 weeks, using low end win98
machines, data is posted on:

http://mozilla.org/performance/startup-data/

intereting data points are:
1.putting overlay back in navigator.xul -> adds 5secs back to total startup time
2.putting menubar, navbar and personal toolbar in navigator.xul -> adds 3 secs
  total (1 sec each) to total startup time 
3.putting sidebar back in navigator.xul -> adds 2 secs back to total startup
  time 
4.disabling CSS, XUL, or JS independently, in 3 seperate builds, don't make much
  improvements in startup time -> pretty much kill the idea that there is a 
  deficiency in one of those big areas




sending to paul. 
Assignee: vishy → pchen
Attached file fastnav.js file
Attached file fastnav.xul file
r=mcafee, does this stuff work?
Please try to keep to 80 chars, the xul file
goes way past that I think.
Yeah, this stuff works. And about the 80 columns, sorry, man, I'm just the guy
paring down navigator.xul. ;-)
fastnav.js, fastnav.xul, and updated jar.mn checked in
what's the pref to switch to fastnav.xul as the default browser window?
pref is "browser.chromeURL", set it to "chrome://navigator/content/fastnav.xul"
nav triage: Paul is done with investigations for this milestone, moving along. 
Target Milestone: mozilla0.9.1 → mozilla0.9.2
I ran some startup/timeline experiments comparing a commercial
optimized build with the default chrome (navigator.xul)
versus pchen's stripped-down chrome (fastnav.xul).

Computer: 650MHz PIII, 512MB, NT 4.0

navigator.xul:
    cold start: 16.614
    warm start: 3.996
    reads from .jar files: 242
    calls to PR_LoadLibrary: 46

fastnav.xul:
    cold start: 13.209
    warm start: 3.135
    reads from .jar files: 102
    calls to PR_LoadLibrary: 42
        
Navigator 4:
    cold start: 10.5 (approximate)
    warm start: 2.9 (approximate)

I've attached the timeline data.  Note the ProfileJARRead call for
each file loaded from a .jar file; these are from the instrumentation
I did for bug 79580.  You can use these to see when files are loaded
(as if all the logging of nsIOService wasn't enough :-)

Not surprisingly, less xul leads to a faster browser!  If we were to
follow my plan, the next step would be to focus on the fastnav.xul
case until its numbers beat the Navigator 4 numbers, add some
functionality back in, and repeat until we have all the features we
want.  In any event, I will do some more analysis on the fastnav.xul
case myself.

Thanks!
-Roger
we're not going to do anything on this in the mozilla0.9.2 & mozilla0.9.3
timeframe. 
Target Milestone: mozilla0.9.2 → mozilla1.0
--> me
Assignee: pchen → blake
Whiteboard: [nav+perf]
Status: NEW → ASSIGNED
Target Milestone: mozilla1.0 → mozilla0.9.3
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Target Milestone: mozilla0.9.4 → mozilla0.9.5
No longer blocks: 7251
Blocks: 7251
Mass moving lower-priority bugs to 0.9.6 (with Blake's pre-consent) to make room
for remaining 0.9.4/eMojo bugs and MachV planning, performance and feature work.
 If anyone disagrees with the new target, please let me know.
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Whoops, this is our #1 performance issue, even if only a placeholder/tracking
bug.  Back to 0.9.5, P1, adding meta keyword, cc pchen, self.
Priority: P2 → P1
Target Milestone: mozilla0.9.6 → mozilla0.9.5
->0.9.6
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Target Milestone: mozilla0.9.6 → mozilla0.9.7
The patch in bug 107642 is an example of the apps-level streamlining that Chris
mentioned, that we're concentrating on.
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Target Milestone: mozilla0.9.9 → mozilla1.1
I'm going to close this because it's not useful to me to have it on my list. We 
are always doing work in this area.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
I'm don't think we should label this as fixed; it is still one of our top
performance issues, the browser still takes too damn long to start, especially
on older machines. While we have made some progress on this, the performance is
still a long way from where we'd ideally like it to be. I think it's useful to
have this placeholder/tracking bug for discussion of general issues and
approaches, for monitoring what progress we are making, and for bugs relating to
specific efforts to improve this to be marked as blocking, so that people with
an interest in this topic can keep up to date on what's being done to improve
things. [And I'd hate for this issue to slip off the radar screen because it was
no longer on the list of open topperf bugs.]

If the problem is simply that it's not useful to you to have it on your list,
then find someone else to own it.

Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Adding the meta keyword that was mentioned earlier. A lot of the bugs hanging
directly off bug 7251 should hang off this one instead. This meta bug should
probably be assigned to a manager type rather than blake.
Keywords: meta
Roger, we have plenty of bugs on startup performance.  I assure you that we're
not going to forget about our performance issues if we close this bug.  Nearly
all of the performance work that the xpapps team does are "application-level
improvements."  I don't know how useful this bug is, but I'll reassign to a
manager-type per dveditz's comments.
Assignee: blaker → dveditz
Status: REOPENED → NEW
stupid brain can't think one person's name and type another's.
Assignee: dveditz → trudelle
accepting for 0.9.9
Status: NEW → ASSIGNED
Target Milestone: mozilla1.1 → mozilla0.9.9
Mass-moving remaining Nav team 0.99 bugs to 1.0.
Target Milestone: mozilla0.9.9 → mozilla1.0
->1.2, since this currently isn't tracking anything.
Target Milestone: mozilla1.0 → mozilla1.2alpha
Product: Browser → Seamonkey
The work to be done on this bug has been done... we can open a new bug if we want to focus on this again.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.