137564 - 100% CPU for a few seconds on loading page with hiermenu

Status: RESOLVED INCOMPLETE

(Core :: Layout, defect)

Description

[Sami Mäkinen]

Highend3D uses fancy JavaScript menus which for some reason totally halt the
browser for a while when loading a new page. Turning JavaScript off fixes this
(but it's a hassle to keep turning it on and off all the time, and the menu
functionality is of course lost).

I'd be just fine if the menus just didn't work right, but that they actually
freeze the whole browser for a while should be fixed somewhere, somehow.

Comment 1

[David Pilcher]

Build 2002041503, Windows 2000 also locks browser for a few seconds after each
page load, with CPU at 100%.

Comment 2

[Phil Schwartau]

Dave: do you have IE6 available? How does that perform on this page?

Comment 3

[David Pilcher]

Tested under IE6.

There is a delay with that too that also momentarily locks up IE.

I guess the response is the same, just under IE the duration of lockup is  a
little less.

I doubt it's a good thing though, since someone could code whatever the menu
javascript is doing - do it recursively - to lockup any browser at the moment.

Comment 4

[Phil Schwartau]

The site uses the "HierMenu" template v4.1.2:

/*HM_ScriptDOM.js
* by Peter Belesis. v4.1.2 011030
* Copyright (c) 2001 Peter Belesis. All Rights Reserved.
* Originally published and documented at http://www.dhtmlab.com/
* Available solely from INT Media Group. Incorporated under exclusive license.
* Contact [e-mail] for more information.
*/


These external scripts are involved:

http://www.highend3d.com/newDesign2/menu/HM_Loader.js
http://www.highend3d.com/newDesign2/menu/HM_ScriptDOM.js
http://www.highend3d.com/newDesign2/menu/HM_Arrays.js


The HM_Loader.js script does the browser-sniffing and loads the 
other two scripts. Depending on the browser, you get a different
version of the HM_Script file. This may explain certain differences
in performance between IE and Mozilla: they are using different
JavaScript files to make the menus.


I will attach a reduced HTML testcase below that contains the
Mozilla version of the file, HM_ScriptDOM.js, in-line, as well
as the other two JS files, (with the loading code in HM_Loader
commented out).

Comment 5

[Phil Schwartau]

Attachment: Reduced HTML testcase: all JS in-line; JS=Mozilla version

Comment 6

[Phil Schwartau]

NOTE: the best way to do performance testing on the reduced
testcase is to save its source and run it locally, to cut out
any network traffic.

When I do this, I do see a difference in CPU usage on page load
between Mozilla trunk 20020415xx and IE6. With Mozilla, the CPU
goes up to 100% for a good three seconds, whereas in IE6 it's only 
about one second. I'm not sure this is very noticeable to the user,
however. I feel much of the delay at the given site may have to
do with the speed of our document.write() when the file HM_Loader.js
loads the other two JS files:


document.write("<SCR" + "IPT LANGUAGE='JavaScript1.2' 
SRC='http://www.highend3d.com/newDesign2/menu/HM_Arrays.js' 
TYPE='text/javascript'><\/SCR" + "IPT>");

document.write("<SCR" + "IPT LANGUAGE='JavaScript1.2' 
SRC='http://www.highend3d.com/newDesign2/menu/HM_Script"+ HM_BrowserString 
+".js' TYPE='text/javascript'><\/SCR" + "IPT>");


Plus all the loading time for all the HTML content I've removed
to make the reduced testcase. Therefore I'm going to reassign this to
DOM Level 0 as a DHTML performance issue. There are many other bug reports
like this involving DHTML menus.


cc'ing self. If I have time, I will investigate this further by editing
the reduced testcase to involve no GUI HTML elements at all, so that
it will consist only of pure JavaScript operations.

Comment 7

[Phil Schwartau]

Confirming and reassigning to DOM Level 0.
OS: Linux ---> All.

Comment 8

[Boris Zbarsky [:bzbarsky]]

fabian, don't we already have bugs on slowness with HierMenu?

Comment 9

[Phil Schwartau]

Note bug 21762, a tracking bug for DHTML performance

Comment 10

[Fabian Guisset]

bz, that would be bug 97287.. sounds about the same

Comment 11

[Phil Schwartau]

Boris, Fabian: thanks. I agree that it's the same issue. In the
other bug, it's HierMenu v4.1 010821; here, it's v4.1.2 011030.

The reduced testcases are pretty much the same in the two bugs.
One advantage of the testcase here is that all the JS is in-line;
the other testcase simply uses HM_Loader to load the other JS files.

I'm going to change the component to Layout to match the other bug.
The diagnosis there seems to be that it's a reflow problem -

Comment 12

[Christine Hoffman]

Changing QA contact

Comment 13

[Markus Hübner]

The HierMenus of webreference.com is the most widely used DHTML library for 
dynamic menus. Also being used by many top100 websites.

Comment 14

[Chris Waterson]

Taking.

Comment 15

[Michael Lefevre]

*** Bug 137976 has been marked as a duplicate of this bug. ***

Comment 16

[Boris Zbarsky [:bzbarsky]]

The testcase attached to the bug no longer works... the original page still
shows a slight CPU spike, but it's not freezing any windows and the page _is_
creating hundreds (if not thousands) of DOM nodes in that onload event.

Comment 17

[Markus Hübner]

There is a short HierMenu testcase I did some time ago - outputing creation 
time: http://www.world-direct.com/hm/nav.html
Maybe this is of some help

Comment 18

[Boris Zbarsky [:bzbarsky]]

Attachment: jprof output

Actually, outputting the creation time in a modal alert is a pain in the behind
when trying to run the page multiple times over and over automatically (only
way to get enough data, since the "cpu spike" is on the order of 2.5 seconds
long on that page....)

Analysis of the profile...

Total hit count: 1493
Top hits:
Count %Total  Function Name
 34   2.3     js_Interpret
 27   1.8     js_LookupProperty
 21   1.4     __pthread_unlock
 20   1.3     nsRuleNode::WalkRuleTree(nsStyleStructID, nsStyleContext *,
nsRuleData *, nsCSSStruct *, int)
 17   1.1     chunk_free
 16   1.1     nsRuleNode::GetStyleData(nsStyleStructID, nsStyleContext *, int)
 14   0.9     nsCOMPtr_base::~nsCOMPtr_base(void)
 14   0.9     __pthread_lock
 13   0.9     chunk_alloc
 12   0.8     nsCOMPtr_base::begin_assignment(void)

Of those 1493 hits, 1308 are inside the handling of the onload event for the
window object (the other 180 or so are the actual page loading).

Of those 1308:
30 are in obj_eval (eval() calls on the page?)
836 are under XPC_WN_GetterSetter() or XPC_WN_CallMethod() (actual calls
through
    xpconnect into gecko)
121 are under nsScriptSecurityManager::CheckObjectAccess (security checks)
The rest seems to be actual JS engine stuff (property lookups, etc); some of
this also goes through XPConnect, of course.

Breakdown of calls to XPTC_InvokeByIndex (709 total; all the XPConnect stuff
goes through here):

		 89 nsGenericHTMLElementTearoff::GetOffsetHeight(int *)
		 56 nsGenericHTMLElementTearoff::SetInnerHTML(nsAString &)
		 41 CSS2PropertiesTearoff::SetTop(nsAString &)
		 41 CSS2PropertiesTearoff::SetLeft(nsAString &)
		 41 nsHTMLDocument::GetElementById(nsAString &, nsIDOMElement
**)
		 40 GlobalWindowImpl::Alert(nsAString &)
		 40 CSS2PropertiesTearoff::SetFont(nsAString &)
		 39 CSS2PropertiesTearoff::SetPaddingRight(nsAString &)
		 37 CSS2PropertiesTearoff::SetFontStyle(nsAString &)
		 35 CSS2PropertiesTearoff::SetWidth(nsAString &)
		 34 CSS2PropertiesTearoff::SetBorderBottom(nsAString &)
		 32 CSS2PropertiesTearoff::SetCursor(nsAString &)
		 32 CSS2PropertiesTearoff::SetBackgroundColor(nsAString &)
		 25 CSS2PropertiesTearoff::SetPadding(nsAString &)
		 22 nsHTMLDivElement::AppendChild(nsIDOMNode *, nsIDOMNode **)
		 17 CSS2PropertiesTearoff::SetColor(nsAString &)
		 12 CSS2PropertiesTearoff::SetHeight(nsAString &)
		 10 CSS2PropertiesTearoff::SetPosition(nsAString &)
		  9 nsGenericHTMLElementTearoff::GetOffsetWidth(int *)
		  7 CSS2PropertiesTearoff::SetVisibility(nsAString &)
		  7 CSS2PropertiesTearoff::SetBorderWidth(nsAString &)
		  6 nsHTMLBodyElement::AppendChild(nsIDOMNode *, nsIDOMNode **)

		  4 CSS2PropertiesTearoff::GetTop(nsAString &)
		  4 CSS2PropertiesTearoff::SetOverflow(nsAString &)
		  3 CSS2PropertiesTearoff::SetBorderColor(nsAString &)
		  3 nsHTMLDivElement::InsertBefore(nsIDOMNode *, nsIDOMNode *,
nsIDOMNode **)
		  3 nsHTMLDivElement::SetId(nsAString &)

and a bunch of things that had one hit each.

Almost all the time in nsGenericHTMLElementTearoff::GetOffsetHeight is sent in
FlushPendingNotifications; most of that is reflow of absolutely positioned
elements, looks like.

Moving on, there are 412 hits total in nsDOMCSSDeclaration::SetProperty, which
is where all the inline style settings fall through to.  Of these 59 are in the
CSS parser parsing the new style, 258 are under
FrameManager::ComputeStyleChangeFor reresolving style, around 50 dealing with
the updated style, the rest scattered about.

Looks like half the style reresolution time is under
nsStyleContext::CalcStyleDifference, almost all of it in GetStyleData
(computation of the new style data).

Summary: Like I said above, there is just too much crap going on; nothing is
standing out as a bottleneck; we're just doing a lot of stuff.

Addendum: if anyone is running with JS strict warnings _ON_, they will add an
extra 50% to the time this testcase takes to run, since the JS is quite poor. 
So don't bother testing with that setting turned on.

Comment 19

[Cees T.]

(In reply to comment #5)
> Created attachment 79373 [details]
> Reduced HTML testcase: all JS in-line; JS=Mozilla version

The images failed to load in Firefox 4.0 Beta 7 on Windows 7 (32 bit), and i didn't see any freeze or CPU spike.

Comment 20

[Matthias Versen [:Matti]]

I can confirm comment#19, this seems to be wfm

Comment 21

[Dave Hunt [:davehunt] [he/him] ⌚BST]

Moving open bugs with topperf keyword to triage queue so they can be reassessed for performance priority.

Comment 22

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months.
:dholbert, could you have a look please?
For more information, please visit auto_nag documentation.

Comment 23

[Daniel Holbert [:dholbert]]

Looks like this is mostly work/investigation from 20 years ago, and the testcase stopped working 10 years ago (possibly because the testcase uses a static IP address in its image URLs in the last few lines, e.g. http://208.179.92.68/gui/new/images/topGuiElementBG2.jpg, which almost certainly is no longer the correct IP address if the image still even exists on some web server).

Closing as INCOMPLETE.