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

ASSIGNED
Assigned to

Status

()

Core
Layout
ASSIGNED
16 years ago
3 years ago

People

(Reporter: Sami Mäkinen, Assigned: Chris Waterson)

Tracking

(4 keywords)

Trunk
Future
perf, testcase, top100, topperf
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

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

Attachments

(2 attachments)

(Reporter)

Description

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

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

Comment 2

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

Comment 3

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

16 years ago
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 licensing@internet.com 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

16 years ago
Created attachment 79373 [details]
Reduced HTML testcase: all JS in-line; JS=Mozilla version

Comment 6

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

16 years ago
Confirming and reassigning to DOM Level 0.
OS: Linux ---> All.
Assignee: rogerl → jst
Status: UNCONFIRMED → NEW
Component: JavaScript Engine → DOM Level 0
Ever confirmed: true
Keywords: perf
OS: Linux → All
QA Contact: pschwartau → desale
Summary: Highend3D pages halt browser for a few seconds on every page load → 100% CPU for a few seconds on evary page load
fabian, don't we already have bugs on slowness with HierMenu?
Summary: 100% CPU for a few seconds on evary page load → 100% CPU for a few seconds on every page load

Comment 9

16 years ago
Note bug 21762, a tracking bug for DHTML performance

Updated

16 years ago
Whiteboard: [HierMenu v 4.1.2]

Comment 10

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

Comment 11

16 years ago
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 -
Assignee: jst → attinasi
Component: DOM Level 0 → Layout
QA Contact: desale → petersen
Whiteboard: [HierMenu v 4.1.2] → [HIERMENU][TOOL][DHTML]

Comment 12

16 years ago
Changing QA contact
QA Contact: petersen → amar

Comment 13

16 years ago
The HierMenus of webreference.com is the most widely used DHTML library for 
dynamic menus. Also being used by many top100 websites.
Keywords: top100, topperf
Hardware: PC → All
(Assignee)

Comment 14

16 years ago
Taking.
Assignee: attinasi → waterson

Comment 15

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

Updated

16 years ago
Keywords: testcase
(Assignee)

Updated

16 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → Future

Updated

16 years ago
Keywords: perf → mozilla1.1

Updated

16 years ago
Keywords: perf
Summary: 100% CPU for a few seconds on every page load → 100% CPU for a few seconds on loading page with hiermenu
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.
Keywords: qawanted

Comment 17

15 years ago
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
Created attachment 121939 [details]
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.
QA Contact: amar → layout

Comment 19

7 years ago
(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.
I can confirm comment#19, this seems to be wfm
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.