RESOLVED FIXED 43808
HTML page using <form> tags with multiple Select lists loads has slow load time 
https://bugs.webkit.org/show_bug.cgi?id=43808
Summary HTML page using <form> tags with multiple Select lists loads has slow load time
pjanoski
Reported 2010-08-10 14:18:31 PDT
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>
Attachments
test case (652 bytes, text/html)
2010-08-11 02:38 PDT, Alexey Proskuryakov 		no flags
Details
/home/pjanoski/Screenshot-1.png (168.98 KB, image/png)
2011-03-03 07:51 PST, pjanoski 		no flags
Details
/home/pjanoski/Screenshot-2.png (150.17 KB, image/png)
2011-03-03 07:52 PST, pjanoski 		no flags
Details
/home/pjanoski/Screenshot-3.png (151.21 KB, image/png)
2011-03-03 07:53 PST, pjanoski 		no flags
Details
/home/pjanoski/Screenshot-4.png (193.57 KB, image/png)
2011-03-03 07:53 PST, pjanoski 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Alexey Proskuryakov
Comment 1 2010-08-11 02:35:41 PDT
Busy computing formElementIndex: WebCore::Element::insertedIntoDocument() WebCore::ContainerNode::insertedIntoDocument() WebCore::HTMLFormControlElement::insertedIntoTree(bool) WebCore::HTMLFormElement::registerFormElement(WebCore::HTMLFormControlElement*) WebCore::HTMLFormElement::formElementIndex(WebCore::HTMLFormControlElement*)
Alexey Proskuryakov
Comment 2 2010-08-11 02:36:32 PDT
<rdar://problem/8296272>
Alexey Proskuryakov
Comment 3 2010-08-11 02:38:30 PDT
Created attachment 64089 [details] test case Same test as an attachment
chris reiss
Comment 4 2011-01-19 12:39:55 PST
I've started on this ...
chris reiss
Comment 5 2011-01-25 13:30:05 PST
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
chris reiss
Comment 6 2011-01-25 13:47:37 PST
... 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 ...
pjanoski
Comment 7 2011-01-28 09:44:06 PST
(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.
chris reiss
Comment 8 2011-01-31 06:53:03 PST
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 ...
pjanoski
Comment 9 2011-01-31 12:31:43 PST
(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.
chris reiss
Comment 10 2011-02-18 08:21:06 PST
Can you provide an example or two of such a page? Thanks.
pjanoski
Comment 11 2011-03-02 12:33:25 PST
(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.
chris reiss
Comment 12 2011-03-02 13:56:00 PST
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.
pjanoski
Comment 13 2011-03-03 07:49:10 PST
(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.
pjanoski
Comment 14 2011-03-03 07:51:27 PST
Created attachment 84561 [details] /home/pjanoski/Screenshot-1.png
pjanoski
Comment 15 2011-03-03 07:52:27 PST
Created attachment 84562 [details] /home/pjanoski/Screenshot-2.png
pjanoski
Comment 16 2011-03-03 07:53:02 PST
Created attachment 84563 [details] /home/pjanoski/Screenshot-3.png
pjanoski
Comment 17 2011-03-03 07:53:40 PST
Created attachment 84564 [details] /home/pjanoski/Screenshot-4.png
Alexey Proskuryakov
Comment 18 2011-03-03 09:24:33 PST
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.
yosin
Comment 19 2012-05-27 18:51:56 PDT
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
Note You need to log in before you can comment on or make changes to this bug.