Very poor DHTML performance on dynamic menus

RESOLVED WORKSFORME

Status

()

Core
Layout
--
major
RESOLVED WORKSFORME
17 years ago
13 years ago

People

(Reporter: Markus Hübner, Assigned: Nisheeth Ranjan)

Tracking

(Blocks: 2 bugs, 5 keywords)

Trunk
mozilla1.2alpha
dom0, dom1, perf, testcase, top100
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [HIERMENU][TOOL][DHTML], URL)

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
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
(Reporter)

Updated

17 years ago
Blocks: 21762
Keywords: dom0, dom1, mozilla0.9.4, nsCatFood, perf
Whiteboard: [HIERMENU][TOOL]
(Reporter)

Comment 1

17 years ago
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
 
Whiteboard: [HIERMENU][TOOL] → [HIERMENU][TOOL][DHTML]
we need a profile of this....

Comment 3

17 years ago
This is probably related to bug 94732. ->waterson,dbaron
Assignee: karnaze → waterson

Comment 4

17 years ago
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

17 years ago
Created attachment 47957 [details]
jprof log using hiermenus during about 30 seconds -- Warning: 400k

Comment 6

17 years ago
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.
(Reporter)

Updated

17 years ago
OS: Windows 2000 → All
Hardware: PC → All
(Reporter)

Updated

17 years ago
Keywords: top100
(Reporter)

Comment 7

17 years ago
suggestion for a better summary
Summary: Very poor DHTML performance → Very poor DHTML performance on dynamic menus
Keywords: mozilla0.9.4 → mozilla0.9.5
(Reporter)

Updated

17 years ago
Keywords: mozilla0.9.4
(Reporter)

Updated

16 years ago
Keywords: mozilla0.9.6
(Reporter)

Comment 8

16 years ago
using build 2001110209 on win2k it seems rendering time is even higher.
any clue on that one?
(Reporter)

Updated

16 years ago
Keywords: mozilla1.0

Updated

16 years ago
Blocks: 113492
(Reporter)

Updated

16 years ago
Keywords: mozilla0.9.8
(Reporter)

Updated

16 years ago
Keywords: testcase

Updated

16 years ago
Target Milestone: --- → Future
(Reporter)

Comment 9

16 years ago
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.
Keywords: mozilla0.9.9

Comment 10

16 years ago
Nisheeth, here's one you can look at.
Assignee: waterson → nisheeth
Target Milestone: Future → ---
JST has done some work optimizing the security checks that should land sometime
soon.
I didn't actually do those changes, mstoltz did. See bug 119646.
Keywords: mozilla0.9.4

Comment 13

16 years ago
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?
(Reporter)

Updated

16 years ago
Blocks: 114584

Updated

16 years ago
Depends on: 75121
(Assignee)

Comment 14

16 years ago
-> 0.9.9
Target Milestone: --- → mozilla0.9.9
(Assignee)

Comment 15

16 years ago
Won't make 0.9.9.  -> 1.0
Target Milestone: mozilla0.9.9 → mozilla1.0

Comment 16

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

Comment 17

16 years ago
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 adt@netscape.com.  You can search for
"Moving bugs not scheduled for a project" to quickly delete this bugmail.
Target Milestone: mozilla1.0 → mozilla1.2

Comment 18

16 years ago
nominating for triage based on email from Markus to adt.
Keywords: nsbeta1
FYI the testcase is 404; you can find other examples via webreference.  Another
bug I think has a working url for this testcase.

Updated

16 years ago
Depends on: 129115
(Reporter)

Comment 20

16 years ago
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/
Keywords: mozilla0.9.5, mozilla0.9.6, mozilla0.9.8, mozilla0.9.9
Blocks: 137564
(Reporter)

Comment 21

16 years ago
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 ?
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.
Keywords: nsbeta1 → nsbeta1-

Comment 23

16 years ago
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

15 years ago
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 :-(
(Reporter)

Comment 25

15 years ago
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

 
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → WORKSFORME

Updated

13 years ago
No longer blocks: 21762
Blocks: 21762
You need to log in before you can comment on or make changes to this bug.