40092 - [PERF] leaving page with many docshells performs O(n^2)

Status: VERIFIED FIXED

(Core :: Layout, defect, P3)

Description

[Jeffrey Baker]

Using Build 2000052109 on i686-pc-linux-gnu, submitting the form at the above
URL takes an extremely long time.  The time needed to submit the form grows more
than O(n) where n is the number of input elements on the page.  To reproduce:

1) Start Moz and navigate to
http://people.netscape.com/morse/wallet/samples/INTERVIEW.HTML

2) Focus the first input and use tab to ge to the Save button at the bottom. 
Note in your terminal that WEBSHELL has incremented to 98.

3) Click the Save button.  Wait.  Longer.  Not yet.  A little more.  OK.  Notice
in your terminal output that the WEBSHELL count decrement was accellerating.  

The expected result is that the HTML Forms code would scale O(n) or better.  On
my 650 MHz AMD machine, this form requires more than 30 seconds to submit.

Comment 1

[Jeffrey Baker]

adding perf keyword

Comment 2

[rods (gone)]

reassigning

Comment 3

[Asa Dotzler [:asa]]

setting to NEW

Comment 4

[Eric Pollmann]

I wonder if this is specific to text input fields.  Is it also a problem when 
leaving a frameset page with many frames?  What I'm getting at is that it may 
not be a form submission problem so much as a problem with tearing down many 
docshells (and the plethora of things they hold on to) because each text input 
field has a docshell...

Comment 5

[Jeffrey Baker]

Attachment: Ignore this attachment, it supports the next one

Comment 6

[Jeffrey Baker]

Attachment: Document with 100 frames

Comment 7

[Jeffrey Baker]

Yes, a frameful document has the same problem.  Check the second attachment. 
Tearing down the page is excruciatingly slow.  I changed the summary to reflect
the actual problem.

Constructing 100 docshells doesn't take too much time.  It just seems like on
certain operations, somebody is walking out to the end of a list to destroy a
docshell, then starting over again from the head of the list.

Comment 8

[Eric Pollmann]

This is painfully slow on all platforms.  CC'ing Adam to see if he is aware of 
this problem.

Comment 9

[Eric Pollmann]

Giving Adam this for now so it doesn't get lost in the Future pile.

Comment 10

[alla]

This seem like a dup of bug 49141. I did a quick profile run of the shutdown,
and it looks like this:
Count   Function Name
1032     gc_find_flags
 516     gc_mark
  83     gc_mark_atom
  28     js_GC

The gc is due to a forced js GC when the JSContext is released in
nsDocShell::Destroy.

Comment 11

[alla]

I meant bug 42321 of course.

Comment 12

[Eric Pollmann]

This is *much* faster with Brendan's recent changes to GC and Johnny's fix to
only GC once per frame destroyed.  On a 350MHz Linux box it only took a few
seconds to leave this the "Document with 100 frames" test case in last night's
build.

Comment 13

[Jeffrey Baker]

5 seconds to flip from the testcase to a cached copy of http://www.yahoo.com/ on
an 800 MHz athlon.  IIRC it used to take over 1 minute.  Fixed?

Comment 14

[Adam Lock]

I'm seeing reasonable load times too so I'm marking fixed. I'm sure it could be
sped even further however.

Comment 15

[ckritzer (gone)]

->gerardok

Comment 16

[bsharma]

qa contact updated.

Comment 17

[bsharma]

The attachment loads in a reasonable amount of time but the status bar still 
says "Transferring data from bugzilla.mozilla.org".
In Netscape 4.7, when I do reload page on the attachment, it loads very fast. 
But, in Netscape 6, it takes the same time and the status bar still says the 
above message. 
Verified on:
build: 2000-03-07-10-Mtrunk
Platform: WinNT

Comment 18

[bsharma]

forgot to change the status to verified.

Comment 19

[James Paige]

ummm, That 100 frame test case takes about 38 seconds (during which the UI was
frozen) to unload when I click the "back" button using build 2001030704 on
Windows 95 on a Pentium 200... I know most people have much faster machines
these days, but considering that Netscape 4.x on the exact same machine takes
less than 4 seconds to go back to the previous page after displaying that
testcase, I think a great deal more enhancement is needed here.

Comment 20

[Heikki Toivonen (remove -bugzilla when emailing directly)]

SPAM. HTML Element component deprecated, changing component to Layout. See bug
88132 for details.