97287 - Very poor DHTML performance on dynamic menus

Status: RESOLVED WORKSFORME

(Core :: Layout, defect)

Description

[Markus Hübner]

Mozilla has a major performance problem (as it has in general with DHTML).
Here is a testcase using the very latest version of the HierMenus, the most 
used menu library on the net.
The building of the menu structure takes double the time it takes on MSIE!

Major usability problems can arise if there seems to be no menus appearing on 
the different sites.
The list of sites using HierMenus is available at (among them several top100)
http://www.webreference.com/dhtml/hiermenus/sites/

Using build 2001082703

Comment 1

[Markus Hübner]

Microsoft just released 6.0 final, increasing the difference between MSIE and 
mozilla once again:

Current status
MSIE 6.0: 2 sec
latest mozilla build: 5,5 sec
 

Comment 2

[Boris Zbarsky [:bzbarsky]]

we need a profile of this....

Comment 3

[karnaze (gone)]

This is probably related to bug 94732. ->waterson,dbaron

Comment 4

[John Morrison]

I had a look at this for while, just breaking in the debugger and looking at
stacks. The most typical stack is a ton of reflow calls triggered from a
request for '.offsetHeight' (or .offsetWidth) generated off a timeout.

<top of stack>
... tons of reflow code ...
PresShell::FlushPendingNotifications()
nsDocument::FlushPendingNotifications()
nsGenericHTMLElement::GetOffsetRect()
nsGenericHTMLElement::GetOffsetHeight()
... from the firing a timeout ...
...

As a measure of how much time was taken up on this code path, I removed the
call 'mDocument->FlushPendingNotifications();' in
'nsGenericHTMLElement::GetOffsetRect()'. That cuts the time to build the menus
in half (reduction of 47%), but unsurprisingly breaks the dhtml menus (like, 
duh!).

Comment 5

[Fabian Guisset]

Attachment: jprof log using hiermenus during about 30 seconds -- Warning: 400k

Comment 6

[Fabian Guisset]

More or less the same results as for bug 83088:
- Half the time (201 / 402) spent in GlobalWindowImpl::RunTimeout
- 7% of the time is spent in nsScriptSecurityManager::CheckPropertyAccessImpl
- 25% in nsGenericElement::HandleDOMEvent which calls itself recursively
- 20% of the time in nsDOMCSSAttributeDeclaration::ParseDeclaration, mainly
called for clip, background-color, and visibility properties.
- 18% (75/402) in PresShell::ProcessReflowCommands 

I guess it's not very different from the usual profile logs we have for DHTML
perf bugs.

Comment 7

[Markus Hübner]

suggestion for a better summary

Comment 8

[Markus Hübner]

using build 2001110209 on win2k it seems rendering time is even higher.
any clue on that one?

Comment 9

[Markus Hübner]

This bug has a major impact on the web's most widely used (also top100 sites) 
DHTML menus (Hiermenus from webreference.com) and is leading to some usability 
problems.
Think we should address this one at least for 1.0 - maybe things will get 
better anyway when a fixing bug 118933.

Comment 10

[Chris Waterson]

Nisheeth, here's one you can look at.

Comment 11

[John Keiser (jkeiser)]

JST has done some work optimizing the security checks that should land sometime
soon.

Comment 12

[Johnny Stenback (:jst)]

I didn't actually do those changes, mstoltz did. See bug 119646.

Comment 13

[Daniel Bratell]

I tried to look at this in Quantify and got bit by a timer thing. Since running 
under Quantify makes everything so much slower it takes longer time to layout 
the page causing many many many more incremental reflows making it take even 
longer time and finally Quantify says that all the time is spent in reflows, 
which is true for the Quantify run but might not be true in general. In this 
case I wonder if not Quantify is telling the truth. 

Then 90% of the time is spent reflowing the page. This is caused by calling 
GetOffsetRect in the script, which as John Morrison says in Comment #4 triggers 
a reflow. It seems as every call to GetOffsetRect causes everything not yet 
reflowed to be reflowed to be able to return a correct value. I assume that 
between the calls to GetOffsetRect the page is changed so that it will have to 
be reflowed again. 

Looking at the reflow time, 

50% is spent in 43000 nsAbsoluteContainingBlock::ReflowAbsoluteFrame
20% is spent in 40000 calls to nsBlockFrame::ReflowDirtyLines

Much of that time is down in CreateRegion and nsViewManager::ResizeView. 

It's hard to say what to do. Maybe the incremental reflowing could be made 
smarter. I don't know what happens between the calls to GetOffsetRect but maybe 
is unnecessary to do as much job just to figure out the offset rect. 

Of the rest of the time (10-50%) depending on how many extra reflows Quantify 
caused itself:

37% is spent in the script evaluation
15% is spent in painting
15% is spent in editor stuff (pressing return in the url bar)
13% is spent in memory allocations inside the js engine
3% is in nsScriptSecurityManager::CanAccess (0.3% - 1.5% of the total)

and so on. But I guess this a pure incremental reflow performance issue. What 
exactly are you doing?

Comment 14

[Nisheeth Ranjan]

-> 0.9.9

Comment 15

[Nisheeth Ranjan]

Won't make 0.9.9.  -> 1.0

Comment 16

[Jo Hermans]

It seems that bug 124683 will solve a part of this (CreateRegion)

Comment 17

[scottputterman]

Moving Netscape owned 0.9.9 and 1.0 bugs that don't have an nsbeta1, nsbeta1+,
topembed, topembed+, Mozilla0.9.9+ or Mozilla1.0+ keyword.  Please send any
questions or feedback about this to [e-mail].  You can search for
"Moving bugs not scheduled for a project" to quickly delete this bugmail.

Comment 18

[scottputterman]

nominating for triage based on email from Markus to adt.

Comment 19

[Randell Jesup [:jesup] (needinfo me)]

FYI the testcase is 404; you can find other examples via webreference.  Another
bug I think has a working url for this testcase.

Comment 20

[Markus Hübner]

The testcase is back online again! 
The list of sites using HierMenus is available at (among them several top100)
http://www.webreference.com/dhtml/hiermenus/sites/

Comment 21

[Markus Hübner]

nice work - using the latest trunk build 2002042903 with bug 129115 the time I 
get went down to 1833ms (on a win-xp,1.1ghz,512ram).
What performance gains can be exptected by bug 124683 ?

Comment 22

[Heikki Toivonen (remove -bugzilla when emailing directly)]

nsbeta1-

Before you renominate, please query bugs marked nsbeta1+ keyword with [ADT# RTM]
in status whiteboard (where # is a number between 1 and 3) and make sure that
this bug is at least as important as those.

Comment 23

[Matthew Mastracci]

Just ran a test of Moz vs. IE 6.0

(rounded values)
IE6.0: 2600, 2300, 2100, 2600

Moz: 1900, 1900, 1900, 2000
(2002052208)

Moz is faster at building the menus and they display smoothly.

Comment 24

[Sebastian Latz]

It's right that Mozilla is faster here than IE - on this page! Take a look at
the Registration window of www.west.de. Klick >>Ja<< on the entry page, and then
>>Login<< at the top in the middle and then >>Registration<<. A new window
should appear where you can eneter your dates. Via Javascript you can scroll
down in this window - with Mozilla 1.1 it's really slow. Even Konqueror does his
Job here better except that he doesn't render this site complete correctly.

Hope it's the right place for that bug here, 'cause there're maany bugs related
to DHTML/JavaScript performance here :-(

Comment 25

[Markus Hübner]

WFM - and very big thanks to all people involved in improving this over time!!

Glad to say that we are doing far better than msie:
MSIE6 SP1: 1282ms
Trunk 2002121908: 911ms