78793 - Performance timeline tracking bug

Status: RESOLVED FIXED

(SeaMonkey :: General, defect)

Description

[Roger Chickering]

I've been working on some light instrumentation of mozilla in
order to develop a timeline of what happens between double click
and the first window that appears.  I'll attach patches to this
bug that others can use to run my experiments as well as results.

-Roger

Comment 1

[Keyser Sose]

Marking NEW.

Comment 2

[Roger Chickering]

Attachment: Timeline test results

Comment 3

[Roger Chickering]

Attachment: patches for instrumention for previous test results

Comment 4

[Roger Chickering]

Attachment: Hand-edited patch that works on my Windows machine

Comment 5

[Roger Chickering]

Attachment: Page used for startup timeline

Comment 6

[Roger Chickering]

Attachment: Hack that prints time in format for timeline service

Comment 7

[Roger Chickering]

Attachment: curtime.exe

Comment 8

[Roger Chickering]

I did some more instrumentation of mozilla with some help
from cathleen and waterson.  The results have been attached
to this bug.  I'm planning to use these results as the basis for the
timeline on the whiteboard at the next perf meeting.

I've also attached patches that include the timeline service
and the instrumentation used to produce the results in case
anyone else wants to try this.  There are two versions of the
patch: the raw "cvs diff" output and a hand-edited version with
hacks to make it work with the version of patch that I have
(cvs diff and patch are not getting along on my NT machine).
Hopefully one of these patches will work for you; otherwise
let me know and I'll be glad to try some other way.

"Page used for startup timeline" is the page I loaded into the
browser; it has an onLoad handler that computes the start-up time; it
should be saved as "page.html" (in c:\temp for the directions below).

"Hack that prints..." is a program that prints out the time in a
format that the timeline service understands.  It should be saved as
"curtime.c" (I also attached curtime.exe if you don't want to compile
it yourself).

OK, now that you have all the pieces, here's how to replicate what I
did:

   1. Apply the patch to a clean tree.
   2. set MOZ_TIMELINE=1
   3. do an optimized build
   4. put curtime.exe in your PATH
   5. Copy this into a shell script (c:\temp\run.sh):
   
      export NS_TIMELINE_LOG_FILE=c:\\temp\\timings.txt
      export NS_TIMELINE_INIT_TIME=`curtime`
      ./mozilla.exe c:\\temp\\page.html?initTime=$NS_TIMELINE_INIT_TIME
   
   6. Run the shell script from the directory dist\WIN32_O.OBJ\bin in
      your build like this:
   
      sh c:\temp\run.sh

Sorry this is so complicated; I'll be happy to help anyone who wants
to follow this steps.  Thanks!

-Roger

Comment 9

[Roger Chickering]

Attachment: Different approach to deciding whether to use RTTI in typeinfo.cpp

Comment 10

[Roger Chickering]

That last patch was meant for another bug.  Maybe I'll figure
out how to use Bugzilla one of these days.

Comment 11

[Roger Chickering]

Attachment: A new patch: works on Linux/Windows/Mac, compiles out completely ifndef MOZ_TIMELIINE

Comment 12

[Roger Chickering]

OK, I'm ready for review.  The idea here is that with a timeline
build you get light-weight instrumentation of mozilla to help
you figure out where time is being spent; this is particularly
applicable to startup time.  My intent is that in normal
(non-timeline) builds these changes will have zero impact on
anything; everything compiles out.

scc: will you please review the xpcom changes?  These are nearly
identical to the changes you looked at earlier under the auspices 
of bug 87698; the changes since then involve porting to the Mac 
and making all of it compile out ifndef MOZ_TIMELINE.

waterson: will you please super-review?  Also, please let
me know if you think I need more reviewers for the instrumentation
I added to netwerk, content, and xpfe.

Thanks!
-Roger

Comment 13

[Roger Chickering]

(one week later):

waterson, scc: I'm happy to let this bug fall off the bottom of my
piority list, so never mind.

If there is renewed interest in getting the timeline code in the
tree, let me know and I'll be glad to help.

Thanks!
-Roger

Comment 14

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I'd like to see it get into the tree.  (At one point I was hoping you'd get it 
in so that I could use it for a page load timeline.  I don't know if I'd have 
the time to work on it now, though.)

One additional feature that might be useful is the ability to have different 
named timelines (e.g., "startup", "pageload", "FileTransport") in the style of 
NSPR logging.

Comment 15

[Cathleen]

we shouldn't let all the good work going to waste!!!

I've got a somewhat working timeline in my local tree now. :-)  The only problem
I'm having now is that the timeline file doesn't report all timing
instrumentation for the entire startup duration.  The url time reports 9.97sec
on warm boot, but my log recored showing up to 5.something seconds and sometimes
up to 8.something seconds...  It's really close now, just need a bit more
tweaking...

Reopening, and reassign to me.

Comment 16

[Cathleen]

-> me

Comment 17

[Roger Chickering]

Oh no!  I think I messed things up when I switched to interval
timers when I ported to the Mac.  I'll take a look.

-Roger

Comment 18

[Roger Chickering]

Hmm, thinks look good for me.  Let's debug this on your
setup when I'm out there on Wednesday.

Comment 19

[Cathleen]

Attachment: updated patch

Comment 20

[Cathleen]

resolve to FIXED.
this was checked in on Friday 8/17