98012 - Browser hangs while loading page [Layout reflow issue]

Status: RESOLVED WORKSFORME

(Core :: Layout, defect)

Description

[womble]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:0.9.3) Gecko/20010801
BuildID:    2001080104

The browser appears to hang while loading the page above.  The throbber runs for
a while, presumably while the page is downloaded.  Then the throbber stops,
processor usage goes up to 100%, and the browser stops repainting its windows
and responding to input (even a close command from the window manager).  No part
of the page is displayed.

It's conceivable that there's a script running on-load that takes a huge amount
of time to run, or that the page has a very complex layout, but I think a minute
is probably long enough to wait (on a 200 MHz K6 processor).  The page displays
reasonably in Netscape 4.73, though it takes a while.  If it turns out that the
apparent hang is due to the script taking a long time then this is a speed
regression in script execution.

Reproducible: Always
Steps to Reproduce:
1. Open the given URL in Navigator.

Actual Results:  Browser hung.

Expected Results:  Page should be displayed.

Comment 1

[Oliver Klee]

Confirming on 2001083103 Win2k on a AMD K6-II+ 500. OS=All and over to
Javascript Engine - the tables on that page are not overly big or complex.

Comment 2

[Phil Schwartau]

This does seem to be JS Engine. The script creates arrays of 237 elements,
each element of which is an array. Then it invokes the sort() method.

I will attach stack traces obtained by interrupting the page load on WinNT.

Comment 3

[Phil Schwartau]

Attachment: WinNT stack traces after interrupting the page load

Comment 4

[Phil Schwartau]

Attachment: Standalone JS shell testcase

Comment 5

[Phil Schwartau]

FINDINGS:

When I load the standalone JS testcase, I see the CPU pegged at 100%
on my WinNT box for about 8-10 seconds. When I load the given URL in a 
Mozilla binary (20010828xx), I see the CPU pegged for about 18 seconds!

IE4.7 seems to take about 10 seconds to load the whole page. I never 
see the CPU go higher than say 55% while it's loading. It briefly spikes
to this level, but spends most of the time between 5% and 10%.

NN4.7 seems to take about as long as Mozilla to load the site,
but does not spend as much time at 100% CPU. It spikes a couple
of times, but does not stay pinned there like Mozilla does -


cc'ing jst, jband: is this purely a JS Engine performance issue?
Do you think the DOM or some other component is underperforming, too? 

cc'ing jrgm in case he would like to add this site to his 
performance suite -

Comment 6

[Carl Kumaradas]

I see exactly the same symptoms when loading http://usopen.org.  Can't follow
Venus-Serena match. :(

Just adding a data-point

Comment 7

[Hans Schleichert]

Found the same in build 2001090808. I had several Mozilla windows open (mail and
some browsers) and when I switched back and forth, the 100% CPU usage would go
away, and the seemingly frozen instance of mozilla displayed the HTML page
correctly. A good example is the Mozilla bug query page which makes heavy use of
JavaScript and HTML forms. Another way to "unfreeze" the browser is to use the
scroll bar, if there is one.

Comment 8

[John Morrison]

(Build 2001090808 was hosed on any page that showed a <select> control
(see bug 98838), and the above comment is not relevant to this bug.)

There are actually two parts to why it takes so long to load that page 
(although nav4.x is no speed demon either). The first part is JS engine,
and the second part is layout (triggered by multiple document.writes).

As Phil notes, there is an 237 element array of arrays that is sorted. This
is slower than IE since (a) mozilla uses quicksort (right?) and that 237-array
is already sorted (hence mozilla goes n-squared; IE apparently uses some heap 
sort), and (b) when sorting an array of arrays, and not given a comparison 
function, mozilla js just flattens each subarray into a string, probably 
chucking the result after each of about 28000 comparisons (and possibly IE
is doing element-wise comparison as long as the elements remain strings and 
numbers, but I can't really prove that).

That web page will load much faster if instead of calling ary.sort(), the 
authors did ary.sort(sortFunc), with 

  function sortFunc(a, b) {
      if (a[0] < b[0])
	  return -1; 
      if (a[0] > b[0])
          return 1;
      return 0;
  }

That cuts the n-squared sort down from about 14 seconds to 0.5 seconds on my 
win2k system (500MHz). [For bonus points, write the JS function to do a 
lexicographic sort element-wise :-)].

So, I leave it to the JS folks to figure out what they want to do with this
bug.

---
Even if you fix the sort problem as above, the page then goes into a second 
phase where it document.write's the <options> into the page (and for bonus
points, wraps each option in a <font> tag). This triggers a complete reflow
of the document for each addition (or that's what it looks like to me). I 
imagine that there are already bugs for that sort of behaviour [is that right
rods? jst? or should I file a bug to investigate what is going wrong 
with the layout phase of this page].

Comment 9

[Phil Schwartau]

cc'ing Brendan re the JS sort algorithm issues - is there something
for JS Engine to fix here? 

Comment 10

[Brendan Eich [:brendan]]

This bug is overloaded.  If you want a purely JS bug, split it off and ask that
JS have a sort implementation that works better on already- or mostly-sorted
inputs.  You might file a second bug asking for faster array.toString code, but
I'm not convinced that's worth improving, just for this bug.  Thanks,

/be

Comment 11

[Phil Schwartau]

I have filed bug 99120 on the "sort implementation should work better
on already- or mostly-sorted inputs" issue.

I'm changing the component on this bug to Layout for the reflow issues
that slow down this page load. As jrgm points out, this might be a
duplicate of some existing Layout bug -

Comment 12

[Kevin McCluskey (gone)]

"the page then goes into a second phase where it document.write's the <options>
into the page (and for bonus points, wraps each option in a <font> tag). This
triggers a complete reflow of the document for each addition (or that's what it
looks like to me). I imagine that there are already bugs for that sort of
behaviour [is that right rods? jst? or should I file a bug to investigate what
is going wrong  with the layout phase of this page]."

Rod is this still an issue. I thought this had been solved a while back?

Reassigning to Rod.

Comment 13

[rods (gone)]

The browser no longer hangs on this page - works for me

If the problem is still there please reopen and and add a complete testcase