Niko Pavlicek wrote:
>
> John Morrison wrote:
>
> > That is absolutely gorgeous! Really nice.
> > [...]
> > It doesn't run as quickly in mozilla as it should. Could you file a bug?
(now http://bugzilla.mozilla.org/show_bug.cgi?id=70156)
> ok, with these changes it works, but there are still many errors [...]
> I got a validated version at
> http://www.html-online.de/niko.temp/time/time.html
What a great test: completely pegs the CPU and runs four to five times slower
than in Communicator, and it's interesting to play with while testing.
I did a quantify run on this in winembed, timing the actions between the
clock starting at one position, moving the mouse across the window, and
stopping quantify when the clock was reformed at the new position. On my
machine in Communicator this takes about 1.5 seconds; in winEmbed and
Mozilla this takes 6 or 7 seconds.
At the highest level, 60% of the time was spent in 71 reflow events, 36% was
spent in the 71 times the timeout function fired (mostly property setting that
triggered style stuff), and 4% in 35 calls to paint the window (of which half
is our rendering code, and half is the OS calls to do the actual painting).
- 4% of time (190msec) was spent in 35 calls to nsWindow::WindowProc,
essentially in painting of the screen
- Down several layers the bulk of that (172msec) is eventually spent in
nsViewManager2::Refresh
- 74% (128msec) spent in 35 calls to nsViewManager2::RenderViews
- 25% (43msec) spent in 35 calls to nsRenderingContextWin::CopyOffScreenBits
- 37% of time (1755 msec) spent in 71 calls to FireTimeout, of which
most was spent in 69 script executions. Those 69 js_interpret calls
generated 1696 js_SetProperty calls, which in turn called
SetCSS2PropertiesProperty 1530 times (1600 msec).
- 9% of that (145msec) spent in 1530 calls to
nsJSUtils::nsConvertJSValToString--more time than in RenderViews!
- 88% (1412msec) total spent in 765 calls each to nsDOMCSSDeclaration
methods SetLeft and SetTop, which each call SetProperty. Nearly all
of this time is spent in nsDOMCSSAttributeDeclaration::ParseDeclaration
- 10% (146msec) in 1530 calls to CSSParserImpl::ParseAndAppendDeclaration,
about half of which comes down to an equal number of nsCSSScanner::ParseNumber
calls. Most of that time is spent in nsString::ToFloat, but there are
an astounding 26,804 calls to nsCString::AppendWithConversion
- 86% (1203msec) in 1530 calls to nsDocument::AttributeChanged, the
bulk of which (1021msec) eventually ends up in NS_NewStyleContext.
A large part of the time spent here is eventually down in 1399 calls
to nsDeviceContextWin::CheckFontExistence (708msec) where we actually
query the OS (GetDC, EnumFontFamiliesA, ReleaseDC) each time.
We need to guard against people who install fonts hundreds of times
a second? For those not following the math, this is a little over
14% of the total time spent checking things that aren't going to change
the world do w
- 59% of the total time (2850msec) spent in 71 calls to md_EventReceiverProc,
which turns out to be ReflowEvent::HandleEvent (we lose 58msec getting
down to that level, though).
This got fairly confusing to follow because the totals didn't add up
(due to cycles or recursion), but at the bottom 30% of the total time,
1525msec, was spent in **11,681** calls to the Win API InvalidateRect.
Other than some of the hot-spots noted above, in this 5 second or so
run other notable function calls were
47,055 calls to "new" (260msec -- 5%)
43,911 calls to "delete" (254msec --5%)
113,173 calls each to PR_Lock and PR_Unlock (160msec together -- 3%)
127,855 calls to ftol (88msec)
13,386 calls to malloc (58msec)
12,357 calls to free (56msec)
508,872 calls to AccumulateCRC (43msec)
82,411 calls to memcpy (43msec)
46,344 calls to memset (34msec)
That's an insane number of function calls to move 22 objects
on the screen 35 times.
Followups set to the performance group
-Dan Veditz
