380.12 KB, text/html
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
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
we need a profile of this....
This is probably related to bug 94732. ->waterson,dbaron
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!).
Created attachment 47957 [details] jprof log using hiermenus during about 30 seconds -- Warning: 400k
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.
suggestion for a better summary
using build 2001110209 on win2k it seems rendering time is even higher. any clue on that one?
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.
Nisheeth, here's one you can look at.
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.
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?
Won't make 0.9.9. -> 1.0
It seems that bug 124683 will solve a part of this (CreateRegion)
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 firstname.lastname@example.org. You can search for "Moving bugs not scheduled for a project" to quickly delete this bugmail.
nominating for triage based on email from Markus to adt.
FYI the testcase is 404; you can find other examples via webreference. Another bug I think has a working url for this testcase.
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/
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.
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.
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