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.
adding perf keyword
setting to NEW
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...
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.
This is painfully slow on all platforms. CC'ing Adam to see if he is aware of this problem.
Giving Adam this for now so it doesn't get lost in the Future pile.
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.
I meant bug 42321 of course.
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.
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?
I'm seeing reasonable load times too so I'm marking fixed. I'm sure it could be sped even further however.
qa contact updated.
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
forgot to change the status to verified.
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.