76705 - application-level improvements to startup

Status: RESOLVED FIXED

(SeaMonkey :: General, defect, P1)

Description

[Chris Waterson]

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

Comment 1

[Chris Waterson]

Attachment: the skinny dip theme

Comment 2

[Chris Waterson]

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

Comment 3

[Viswanath Ramachandran]

Need to investigate this in the m0.9.1 timeframe. 

Comment 4

[chris hofmann]

adding topperf.  startup is still our sore thumb..

Comment 5

[Chris Waterson]

I think new-window is our sore thumb. I'm eating donuts during startup anyway.

Comment 6

[chris hofmann]

if the *first* new window gets faster do the subsquent new windows get faster?
I each a donut for each new window that opens.

Comment 7

[Chris Waterson]

> 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.

Comment 8

[Blake Ross]

I wonder how Joe's stylesheet scoping will help here...

Comment 9

[Joe Hewitt (gone)]

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.

Comment 10

[Cathleen]

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.  :-)

Comment 11

[Viswanath Ramachandran]

nav triage: yes this needs to be done for mozilla0.9.1.

Comment 12

[Blake Ross]

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.

Comment 13

[Cathleen]

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

Comment 14

[Viswanath Ramachandran]

sending to paul. 

Comment 15

[Paul Chen]

Attachment: add fastnav.xul and fastnav.js to comm.jar

Comment 16

[Paul Chen]

Attachment: fastnav.js file

Comment 17

[Paul Chen]

Attachment: fastnav.xul file

Comment 18

[Chris McAfee]

r=mcafee, does this stuff work?
Please try to keep to 80 chars, the xul file
goes way past that I think.

Comment 19

[Paul Chen]

Yeah, this stuff works. And about the 80 columns, sorry, man, I'm just the guy
paring down navigator.xul. ;-)

Comment 20

[Ben Goodger (use ben at mozilla dot org for email)]

sr=[e-mail]

Comment 21

[Paul Chen]

fastnav.js, fastnav.xul, and updated jar.mn checked in

Comment 22

[Cathleen]

what's the pref to switch to fastnav.xul as the default browser window?

Comment 23

[Paul Chen]

pref is "browser.chromeURL", set it to "chrome://navigator/content/fastnav.xul"

Comment 24

[Viswanath Ramachandran]

nav triage: Paul is done with investigations for this milestone, moving along. 

Comment 25

[Roger Chickering]

Attachment: timings.zip: timeline data for fastnav.xul v. navigator.xul, cold and warm start

Comment 26

[Roger Chickering]

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

Comment 27

[Viswanath Ramachandran]

we're not going to do anything on this in the mozilla0.9.2 & mozilla0.9.3
timeframe. 

Comment 28

[Blake Ross]

--> me

Comment 29

[Peter Trudelle]

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.

Comment 30

[Peter Trudelle]

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.

Comment 31

[Asa Dotzler [:asa]]

->0.9.6

Comment 32

[Blake Ross]

The patch in bug 107642 is an example of the apps-level streamlining that Chris
mentioned, that we're concentrating on.

Comment 33

[Blake Ross]

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.

Comment 34

[Roger D]

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.

Comment 35

[Daniel Veditz [:dveditz]]

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.

Comment 36

[Blake Ross]

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.

Comment 37

[Blake Ross]

stupid brain can't think one person's name and type another's.

Comment 38

[Peter Trudelle]

accepting for 0.9.9

Comment 39

[Peter Trudelle]

Mass-moving remaining Nav team 0.99 bugs to 1.0.

Comment 40

[Peter Trudelle]

->1.2, since this currently isn't tracking anything.

Comment 41

[Andrew Schultz]

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.