399403 - One function on microsoft.com is extremely slow

Status: RESOLVED WONTFIX

(Core :: DOM: Core & HTML, defect, P5)

Description

[Robert Sayre]

This function is found on all of their big sites it seems. msn.com, etc.

Comment 1

[Robert Sayre]

Attachment: gzip of site

ms/www.microsoft.com/index.html will run the function

Comment 2

[Robert Sayre]

Attachment: TI() is the function, it looks like this

Comment 3

[Robert Sayre]

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

[Boris Zbarsky [:bzbarsky]]

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

[Firefox Bug Husbandry Bot]

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.

Comment 6

[Henri Sivonen (:hsivonen) (not reading bugmail until 2026-07-27)]

Does not seem relevant anymore.