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!).

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?

-> 0.9.9

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 adt@netscape.com. 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/

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.

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 :-(

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