218308 - 5+mins to render Javascript menu page that IE renders in a few seconds (getElementById)

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[David Jung]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030820 Mozilla Firebird/0.6.1+
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030820 Mozilla Firebird/0.6.1+

The supplied URL contains a frame with a javascript menu (generated by doxygen)
that takes 100% CPU for more than 5mins to render (i686 1.2GHz), where IE takes
just a few seconds.  The browser UI is unresponsive during that time.
This makes the page essentially unusable.


Reproducible: Always

Steps to Reproduce:
1. Visit URL
2. Wait
3. Wait longer...

Actual Results:  
took >5mins to render

Expected Results:  
Should take <10 seconds at least - prefer near speed of IE.

I'm no Moz developer, but it *may* be related to these bugs:
40988 & 87165.
Although I'm using Firebird, is also occurs in Mozilla 1.4 any probably earlier.
(hence my guess that it is a Javascript problem)

Comment 1

[Doron Rosenberg (IBM)]

IE 6 hangs on that page as well, get a dialog that a script is running slow,
press cancel, UI not responsive, on a p4.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Not likely to be a JS engine bug.  Someone needs to profile this to determine
the slow point...

Comment 3

[Doron Rosenberg (IBM)]

tor did, kicking to layout for now.

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: jprof profile (gzipped html)

This makes it look like we're doing repeated frame recreation due to attribute
changes.

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Er, due to setting of .style.display, not attribute changes.

Comment 6

[Daniel Wang]

Attachment: (non-reduced) testcase

the script is very inefficient. it has code like
  document.write('<div>');
  document.write('text');
  document.write('</div>');
instead of
  s = "<div>";
  s = s + text;
  s = s + "</div>";
  document.write(s);

this attachment has more efficient doc.write code. Still, Mozilla renders as
slowly as MSIE5.0 (both ~2min)

Comment 7

[Doron Rosenberg (IBM)]

right, the code is very inefficient.  However, Opera 7 seems to do it much
faster than IE and Gecko :)

Comment 8

[Boris Zbarsky [:bzbarsky]]

Hmm... What is the site setting .style.display on and to, exactly?

Comment 9

[Andrew Schultz]

Venkman says the most time is spent in

initializeDocument
  initializeFolder
    initializeItem
      drawItem (31%, document.write, including "style='display:block'")
  clickOnNode
    setStateFolder
      propagateChangesInState
        hideFolder (recursively calls setStateFolder)
        hideItem (59%, sets display=none on <div>s written in drawItem)

Comment 10

[Chris Wood]

Page seems to have disappeared.

Comment 11

[David Jung]

Corrected/updated URL.  Confirmed problem still present in Firefox 1.0.1.  It
seems to render faster than before, although my machine has been upgraded since
then (and I just tried on the WinXP version of firefox, whereas before it was
the Linux version)

Comment 12

[Boris Zbarsky [:bzbarsky]]

OK, I just reprofiled the URL in the URL field.  The verdict is:

1)  All our time is spent under executing the <script> element.
2)  About 80% of the time is spent under XPTC_InvokeByIndex
3)  Of this 80%, about half is under nsHTMLDocument::GetElementById.  The rest
    is under nsHTMLDocument::Write and nsContentList::NamedItem.

The script is basically calling document.getElementById and
document.images.namedItem on every single thing it writes out.  And every time
we walk the DOM from the top looking for the thing with the new id, which is
deathly slow.

We could optimize MatchElementId a bit to do less string-munging and looking for
attrs, but that wouldn't solve the basic algorithmic problem here.

Given that we already do all the work of looking for the ID, etc when we add a
node with an id to the document, might it be worth it to add it to the hashtable
at that point instead of just updating if there is an entry for that id already?

Comment 13

[Boris Zbarsky [:bzbarsky]]

On a separate note, that page executes one set of code in IE and Opera and a
very different set of code in Mozilla.  So it's not clear how relevant the
performance comparison is.

Comment 14

[José Jeria]

The summary is not really true anymore. I tested the url and got these results:

IE 6:			60 secs
Moz (20050407 ):	28 secs
Opera 8, beta 3:	14 secs

One difference was that IE 6 prompted me to abort the script pretty fast.
Mozilla never did. 
Tested on XP sp1 on a intel celeron 2.40 ghz computer, 512 mb ram.

Comment 15

[Erik Fabert]

Attachment: revised testcase

This is basically the same testcase (99% as inefficient as before) but I
replaced the text with some dummy strings and removed the browser switches, so
the results of different browsers should be comparable.

Test results on my machine: 
Deer Park A2 30 sec, IE6 54 sec, Opera 8.01 4.5 sec.

Comment 16

[Boris Zbarsky [:bzbarsky]]

This should be retested once bug 299689 is fixed.

Comment 17

[Nikolay]

In the newest version of Doxygen it seems that the tree is generated in a
different manner. However IE still seems to render the page much quicker than
Firefox. There is a short disucssion here:
http://sourceforge.net/mailarchive/forum.php?forum_id=1985&max_rows=25&style=flat&viewmonth=200508&viewday=11
I am wondering if a new bug report should be opened against firefox to address
the performance issues with the latest version of Doxygen?

Comment 18

[Boris Zbarsky [:bzbarsky]]

Yes, please file a new bug with a URL that shows the problem and cc me on it.

Comment 19

[Nikolay]

I have created bug 304683 as requested

Comment 20

[Caleb]

Some test results after the checkin of bug 299689:

Firefox: Elapsed time: 10,625ms. 
IE6: Elapsed time: 32,875ms. 

Nice!

Comment 21

[Boris Zbarsky [:bzbarsky]]

Try Opera.  I'd expect a number in the 3000 range on your hardware...

Comment 22

[Caleb]

(In reply to comment #21)
> Try Opera.  I'd expect a number in the 3000 range on your hardware...

My previous test results were on a work computer.. Here are my complete results
on my home computer (P4 2.8Ghz - Hyperthreading Enabled)

Firefox: Elapsed time: 6,812ms. 
IE6 SP1: Elapsed time: 29,703ms. 
Opera 8.02: Elapsed time: 2,422ms.

Opera seems to be the most responsive, since it seems to actually show whatever
is going on instead of hanging until the script is done.

Comment 23

[Johnny Stenback (:jst)]

The fact that Opera's JS execution is async (not sync like it is in Mozilla and
IE) would explain that...

Comment 24

[Wayne Mery (:wsmwk)]

WFM? 

1,900ms for Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20081222 Shiretoko/3.1b3pre

Comment 25

[Boris Zbarsky [:bzbarsky]]

Yeah, I probably should have marked this WFM after comment 20.  We're still a bit slower than Opera or webkit on this testcase, but that should probably be a separate bug.

Comment 26

[Carlos Alén Silva]

Mark as resolved WFM?

Comment 27

[Lars Gunther]

WFM seems appropriate.

Revised test case takes 2470 ms on my Thinkpad Z61p (3 years old hardware), running Firefox 3.5.9 on Fedora 12

Mozilla/5.0 (X11; U; Linux i686; sv-SE; rv:1.9.1.9) Gecko/20100330 Fedora/3.5.9-2.fc12 Firefox/3.5.9

1580 ms on the latest nightly.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a5pre) Gecko/20100418 Minefield/3.7a5pre

Google Chrome 5 beta for Linux is 3.5x slower: 5610 ms (5.0.342.9 beta)

Comment 28

[Boris Zbarsky [:bzbarsky]]

Actually, just fixed by bug 299689.