John Lee Reporter
	Description • 19 years ago

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.0.2) Gecko/20060308 Firefox/1.5.0.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.0.2) Gecko/20060308 Firefox/1.5.0.2

Firefox takes an unpectedly long time to load:
  - <input type="checkbox">, 
  - <input type="text">, 
  - <input type="radio">, 
  - <select>, and 
  - <textarea> 

This observation is in comparison to loading other HTML elements like: 
  - <input type="button">, 
  - <button>, 
  - <h1>, 
  - <p> and 
  - <img> 
in which Firefox loads them near instantaneously. I have not tested the performance of other HTML elements.

The observation is also done in comparison to other competing browsers like MSIE 6.0 and Opera 8.5. MSIE 6.0 loads the pages equally fast. I have not checked fully with Opera 8.5 or Opera 9.0 Beta.

I just realised that I have not checked <input type="file">.

Reproducible: Always

Steps to Reproduce:
1. Create a simple HTML page with several hundred or several thousand <input type="text">.
2. Load the page in Firefox and compare how other browsers handle the same page (like Internet Explorer)
3. Repeat the same test with the same number of <select>, <textarea>, <h1>, <p>, <img> and other HTML elements.

Actual Results:  
Firefox 1.5.0.2 and Minefield 3.0a1 (Gecko/20060429) takes an abnormally long time to load the pages with lots of <input type="text">, <select> and <textarea>. Doing the same test with <h1>, <p> and <img> reveals a performance comparable to MSIE 6.0 -- near instantaneous.

On a AMD Athlon 64 X2 3800+, it took less than 30 seconds to load the page with 10,000 <input type="text"> elements. If you wish to try the tests on older machines, you may want to use several hundred or thousand elements instead. No real need to wait for 10 minutes just to say, "Yes, there is a performance problem." :-)

My test with 10,000 <select> elements also showed an additional problem. A weird windowing bug, I guess. It's hard to describe because I've never seen it before. I can say that it was difficult to access the Windows Task Manager to kill the Firefox process.

Firefox takes about as much time to load the same test pages in XHTML.

Also, when closing Firefox so that I can repeat the tests with other elements, Firefox takes nearly as much time to close the process as it did to load the test pages.

Expected Results:  
Firefox to load the <input type="checkbox">, <input type="radio">, <input type="text">, <select> and <textarea> as fast as other HTML elements.

MSIE 6.0 and Opera 8.5 behaves as expected.

This bug is probably related to https://bugzilla.mozilla.org/show_bug.cgi?id=332558

	John Lee Reporter
	Comment 1 • 19 years ago

Attached are the some of the testcases I used to test the bug. The HTML pages within contains 10,000 elements of each element needed to clearly show a performance problem in an AMD Athlon 64 X2 3800+.

	Kevin Brosnan
	Comment 2 • 19 years ago

Sounds close to Bug 148636 - Enormous memory usage rendering with lots of form elements.

	Boris Zbarsky [:bzbarsky]
	Comment 3 • 19 years ago

There are probably multiple things going on here; if nothing else, <input> and <select> have totally different issues and need separate bugs; there are probably already bugs tracking performance of both (though if there aren't, they should be filed).

For <input> there's at least bug 148636 and bug 221820.  The changes I made for bug 221820 locally make a testcase with 1000 <input>s about twice as fast (from 2s down to 1s on a P3-733).

I did profile the 10000-<input> testcase a bit.  I see a rather large amount of time being spent inside nsContentList::BringSelfUpToDate (at least 68% of total).  All of that time is under nsContentUtils::GenerateStateKey calling nsContentList::IndexOf.  I'll dig a little more and file a followup bug on that as needed or comment here.

	Boris Zbarsky [:bzbarsky]
	Comment 4 • 19 years ago

Filed bug 336062 on the issue I found.  That might actually help <select> too; please retest once that patch lands?

	John Lee Reporter
	Comment 5 • 19 years ago

(In reply to comment #4)
> Filed bug 336062 on the issue I found.  That might actually help <select> too;
> please retest once that patch lands?
> 

I will do that when that patch lands. Thanks.

Also thank you for showing that using a form to enclose the form controls helps. I wasn't using a form because I was working with XMLHTTPRequest and this problem showed up clearly with less form controls on an Pentium 3 650 MHz.

Redoing the tests with a <form>, 10,000 <input type="text"> takes 5 seconds, 10,000 <textarea> takes around 18 seconds and 10,000 <select> in 1+ minute on the X2 3800+. Closing Firefox in all cases is also a lot faster and doesn't seem to be related to the page load time.

Also for the windowing bug on a lot of selects, with a form, after a while of loading the page Firefox visually bleeds onto the desktop and other opened windowed programs. And there is also a visual jump of the Firefox window to the upper left corner of the desktop but the program had actually remained where it was.

Once the page was loaded, Firefox is stable, although slow to scroll the page. I can recover from the bleeding on the other opened programs by getting Windows to repaint the programs, like moving it offscreen or hiding behind another window.

	Aaron Leventhal
	Comment 6 • 18 years ago

I notice that our layout of the textarea has changed since Gecko 1.8.

	Aaron Leventhal
	Comment 7 • 18 years ago

Comment on attachment 232265 [details]
Another testcase: missing caret at end of first line for Windows

Sorry, wrong bug.

	Carlos Alén Silva
	Comment 9 • 9 years ago

Since the bugs this bug depends on have been fixed, can this bug be closed?