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

VERIFIED FIXED

Status

()

Core
Layout
P3
normal
VERIFIED FIXED
18 years ago
16 years ago

People

(Reporter: Jeffrey Baker, Assigned: Adam Lock)

Tracking

({perf, testcase})

Trunk
perf, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

18 years ago
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.
(Reporter)

Comment 1

18 years ago
adding perf keyword
Keywords: perf

Comment 2

18 years ago
reassigning
Assignee: rods → pollmann

Comment 3

18 years ago
setting to NEW
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 4

18 years ago
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...
Status: NEW → ASSIGNED
(Reporter)

Comment 5

18 years ago
Created attachment 9914 [details]
Ignore this attachment, it supports the next one
(Reporter)

Comment 6

18 years ago
Created attachment 9915 [details]
Document with 100 frames
(Reporter)

Comment 7

18 years ago
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.
Summary: [PERF] Submitting form with many inputs performs O(n^2) → [PERF] leaving page with many docshells performs O(n^2)

Comment 8

18 years ago
This is painfully slow on all platforms.  CC'ing Adam to see if he is aware of 
this problem.
Component: HTML Form Controls → HTML Element
OS: Linux → All
Hardware: PC → All

Comment 9

18 years ago
Giving Adam this for now so it doesn't get lost in the Future pile.
Assignee: pollmann → adamlock
Status: ASSIGNED → NEW

Updated

18 years ago
Target Milestone: --- → M19
(Reporter)

Updated

17 years ago
Keywords: testcase

Comment 10

17 years ago
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

17 years ago
I meant bug 42321 of course.

Comment 12

17 years ago
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.
(Reporter)

Comment 13

17 years ago
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?
(Assignee)

Comment 14

17 years ago
I'm seeing reasonable load times too so I'm marking fixed. I'm sure it could be
sped even further however.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 15

17 years ago
->gerardok

Updated

17 years ago
QA Contact: ckritzer → gerardok

Comment 16

17 years ago
qa contact updated.
QA Contact: gerardok → bsharma

Comment 17

17 years ago
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

17 years ago
forgot to change the status to verified.
Status: RESOLVED → VERIFIED

Comment 19

17 years ago
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.
SPAM. HTML Element component deprecated, changing component to Layout. See bug
88132 for details.
Component: HTML Element → Layout
You need to log in before you can comment on or make changes to this bug.