Performance issue using val() in Firefox

[Mottie]

When setting the value of a select, Firefox takes about twice as long to set the value using jQuery's val() versus using the plain javascript value method.

When this demo (​http://jsfiddle.net/Mottie/L35b4b34/4/) is run in Chrome and IE, the percent difference is minimal:

In a select with 25,000 options

Browser  |   val() |  value
Chrome36 |  256 ms |  232 ms
IE10     | 3510 ms | 3203 ms
FF31.0   |  809 ms |  304 ms

[Mottie]

Oops, sorry, I shared the wrong demo and times... those times include both setting the HTML and value of the selects

Use this demo instead (10,000 options; IE doesn't choke as often): ​http://jsfiddle.net/Mottie/L35b4b34/7/

Browser  |  val() | value
Chrome36 |  24 ms |  3 ms
IE10     | 118 ms | 10 ms
FF31.0   | 306 ms |  0 ms

[gibson042]

In addition to working around browser bugs, .val must function correctly for both select-one and select-multiple elements. We've historically chosen to optimize it for code size. Are 10,000-option selects required by your application, and is this actually a bottleneck for you?

There's no shame in dropping out of jQuery to improve performance with native functionality when it really matters, especially if your case is unusual in the broader ecosystem.

[Mottie]

I opened this issue due to a pull request on the plugin I support (​https://github.com/Mottie/tablesorter/pull/711). I don't know if he actually does have 25k pages to add to the page selector, or if it is just some arbitrary number; but there is a noticeable difference.

I agree this is probably an edge case, but I still plan on switching over to pure javascript in this case because the combination of setting both HTML and val displays an "Unresponsive script" warning" in Firefox.

[gibson042]

Thanks very much. My inclination is to let this go unless the size/performance tradeoff changes substantially.