Bug 43808

Summary:

HTML page using <form> tags with multiple Select lists loads has slow load time

Product:

WebKit

Reporter:

pjanoski

Component:

DOM

Assignee:

Nobody <webkit-unassigned>

Status:

RESOLVED FIXED

Severity:

Critical

CC:

ap, christopher.reiss, yosin

Priority:

Keywords:

InRadar

Version:

528+ (Nightly build)

Hardware:

All

OS:

All

Attachments:

Description	Flags
test case	none
/home/pjanoski/Screenshot-1.png	none
/home/pjanoski/Screenshot-2.png	none
/home/pjanoski/Screenshot-3.png	none
/home/pjanoski/Screenshot-4.png	none

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.