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)

x86
SunOS
defect

Tracking

()

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.
Attached file gzip of site
ms/www.microsoft.com/index.html will run the function
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
Keywords: perf
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.  :(
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
Component: DOM → DOM: Core & HTML
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.