Using <form></form> with multiple select lists in an HTML document (selects with 1500 items loaded via javascript) loads slower than without the <form> tags. There is a noticeable increase in page load time (about +10 seconds on a standard Windows PC running XP). The following listing shows the code with and the <form> tags which cause the increased page load time. Listing 1: (causes slow page loading) PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html> <head> </head> <body bgcolor="#e5e5e5"> <form> <select id="sel1"></select> <select id="sel2"></select> <select id="sel3"></select> <select id="sel4"></select> <select id="sel5"></select> <select id="sel6"></select> <select id="sel7"></select> <select id="sel8"></select> <select id="sel9"></select> <select id="sel10"></select> </form> <script type="text/javascript"> var str=''; for (var i = 0; i < 1500; i++) { str += "<option value=" + i + ">" + "some text goes here " + i + "<\/option>"; } for (var i = 1; i <= 10; i++) { var ele = document.getElementById('sel' + i); ele.innerHTML = str; } </script> </body> </html> The following listing contains the same code without the <form> tags. This version runs much faster with no noticable degradation: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html> <head> </head> <body bgcolor="#e5e5e5"> <select id="sel1"></select> <select id="sel2"></select> <select id="sel3"></select> <select id="sel4"></select> <select id="sel5"></select> <select id="sel6"></select> <select id="sel7"></select> <select id="sel8"></select> <select id="sel9"></select> <select id="sel10"></select> <script type="text/javascript"> var str=''; for (var i = 0; i < 1500; i++) { str += "<option value=" + i + ">" + "some text goes here " + i + "<\/option>"; } for (var i = 1; i <= 10; i++) { var ele = document.getElementById('sel' + i); ele.innerHTML = str; } </script> </body> </html>
Busy computing formElementIndex: WebCore::Element::insertedIntoDocument() WebCore::ContainerNode::insertedIntoDocument() WebCore::HTMLFormControlElement::insertedIntoTree(bool) WebCore::HTMLFormElement::registerFormElement(WebCore::HTMLFormControlElement*) WebCore::HTMLFormElement::formElementIndex(WebCore::HTMLFormControlElement*)
<rdar://problem/8296272>
Created attachment 64089 [details] test case Same test as an attachment
I've started on this ...
I took a first pass at this, and was wondering if this is really of interest (worth patching). I found that by caching element-id's in
... in a hash-map (which empties in the event of a deletion or insertion in the DOM tree) and found : In the given test case, the page-load-time drops by 20 secs or so (a debug build on Ubuntu, 2.8 GHz processor). In a more realistic scenario, where a select-box for 'year' might have 100 options, i saw a savings of 6 milliseconds. I expect there must be some page somewhere which does a lot of this ... wd appreciate feedback on whether this is worth pursuing ...
(In reply to comment #6) > ... in a hash-map (which empties in the event of a deletion or insertion in the DOM tree) and found : > > In the given test case, the page-load-time drops by 20 secs or so (a debug build on Ubuntu, 2.8 GHz processor). > > In a more realistic scenario, where a select-box for 'year' might have 100 options, i saw a savings of 6 milliseconds. > > I expect there must be some page somewhere which does a lot of this ... wd appreciate feedback on whether this is worth pursuing ... Yes, can you please provide example of what the HTML code etc. would look like to use the hash-map. Slow initial-load time because items are not cached yet would not be acceptable. Also, ~1500 options per select-box is the realistic scenario or norm for the application.
The HTML would be unaffected by this patch, it would just render lots faster. Is there really a live page with 1500 elements in a select box ? This case looks like it was written to stress this functionality, but would make for a rather weird user experience ...
(In reply to comment #8) > The HTML would be unaffected by this patch, it would just render lots faster. > > Is there really a live page with 1500 elements in a select box ? This case looks > like it was written to stress this functionality, but would make for a rather weird user experience ... The patch would be much appreciated and also yes there is a select box (actually many) in a live page with ~1500 elements.
Can you provide an example or two of such a page? Thanks.
(In reply to comment #10) > Can you provide an example or two of such a page? Thanks. The initial simple example that shows the problem in Listing 1 should be sufficient.
That doesn't seem like a 'live page' - an actual working web page in the wild. Any patch to this area risks a regression down the road; without a live page which demonstrates benefit to the end-user, webkit reviewers won't approve the patch even if i submit it.
(In reply to comment #12) > That doesn't seem like a 'live page' - an actual working web page in the wild. > > Any patch to this area risks a regression down the road; without a live page which demonstrates benefit to the end-user, webkit reviewers won't approve the patch even if i submit it. We have a POS application being used by 100k+ people. Attached are some screenshots using drop downs containing large (+1500 item) lists of items.
Created attachment 84561 [details] /home/pjanoski/Screenshot-1.png
Created attachment 84562 [details] /home/pjanoski/Screenshot-2.png
Created attachment 84563 [details] /home/pjanoski/Screenshot-3.png
Created attachment 84564 [details] /home/pjanoski/Screenshot-4.png
It seems like a lot of people would benefit from a re-design that wouldn't employ such huge popup menus. Regardless of how fast WebKit renders them, using them must be a pain.
This bug should be fixed by BUG-79764 which fixed http://crbug.com/90094 Note: There is another performance issue regarding to "option" element within "optgroup", BUG-87466