Open
Bug 399403
Opened 17 years ago
Updated 2 years ago
One function on microsoft.com is extremely slow
Categories
(Core :: DOM: Core & HTML, defect, P5)
Tracking
()
NEW
People
(Reporter: sayrer, Unassigned)
Details
(Keywords: perf)
Attachments
(2 files)
This function is found on all of their big sites it seems. msn.com, etc.
Reporter | ||
Comment 1•17 years ago
|
||
ms/www.microsoft.com/index.html will run the function
Reporter | ||
Comment 2•17 years ago
|
||
Reporter | ||
Comment 3•17 years ago
|
||
Comment on attachment 284409 [details]
TI() is the function, it looks like this
oh, you'll find it in ms/i2.microsoft.com/h/all/s/13.5_rtw/hp.js
Comment 4•17 years ago
|
||
jprof of just this function seems to be too big to attach here (600+ KB compressed) but basic summary is: Total hit count: 29837 27416 of them under NS_InvokeByIndex_P (call from JS into C++) 17868 nsGenericHTMLElementTearoff::GetOffsetHeight 7125 nsGenericHTMLElementTearoff::SetInnerHTML 1179 nsGenericHTMLElementTearoff::GetInnerHTML 656 nsHTMLTableCellElement::SetClassName 376 nsHTMLDocument::GetElementByIdnsIDOMElement**) Under SetInnerHTML, there's the usual mess of content changes. Under GetOffsetHeight, as expected we have: 14586 PresShell::ProcessReflowCommands(int) 3253 nsCSSFrameConstructor::ProcessPendingRestyles() The relevant JS code is this, from the helpful pastebin: for(var x = 0; x < tbCount; x++){ FT(x); node = G('tbc_0'); tblMaxHeight = ((node.offsetHeight > tblMaxHeight) ? node.offsetHeight : tblMaxHeight); } where FT(x) does: function FT(i){ var cPh; if(tbarr != null) { if(cTab>-1) { cPh = G('tbh_' + cTab); cPh.className = 'Normal'; } cPh = G('tbc_0'); cPh.innerHTML = tbarr[i]; cPh = G('tbh_' + i); cPh.className = 'Hilite'; cTab = i; } } So basically, for every one of those rows (6 in total) we change some content, then get an offsetHeight... which means processing the restyles from that className change and processing whatever relayouts are pending. In this case, we probably pretty much fully reflow whatever tale is involved 6 times, since content changes inside a table can affect widths of every single cell, etc. We have 12775 hits under nsTableOuterFrame::OuterReflowChild and about 2/3 of that is recomputing column intrinsic widths for the table. If they need the up-to-date layout data there's not much to be done here, but otherwise the way to make this better is to either restructure the code or to figure out how we can optimize the flushing we do somewhat. :(
Comment 5•6 years ago
|
||
https://bugzilla.mozilla.org/show_bug.cgi?id=1472046 Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5. If you have questions, please contact :mdaly.
Priority: -- → P5
Assignee | ||
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•