Build 2002041503, Windows 2000 also locks browser for a few seconds after each page load, with CPU at 100%.
Dave: do you have IE6 available? How does that perform on this page?
Confirming and reassigning to DOM Level 0. OS: Linux ---> All.
Assignee: rogerl → jst
Status: UNCONFIRMED → NEW
Ever confirmed: true
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
Note bug 21762, a tracking bug for DHTML performance
bz, that would be bug 97287.. sounds about the same
16 years ago
Depends on: 97287
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]
Changing QA contact
QA Contact: petersen → amar
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: attinasi → waterson
*** Bug 137976 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
Target Milestone: --- → Future
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.
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.
(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
You need to log in before you can comment on or make changes to this bug.