Improve performance of SELECT element by optimizing Vector.

Improve performance of SELECT element by optimizing Vector.

Replace Vector::clear() with Vector::resize(0) to avoid to deallocate Vector
buffers.

Removing 20,000 OPTIONs: 7,595ms -> 5,779ms

BUG=620142, 624220
Committed: https://crrev.com/8881397e890dd70a187a957ae6910f141d378eb5
Cr-Commit-Position: refs/heads/master@{#402720}

[tkent, 2016-06-29 01:21:52]

tkent@chromium.org changed reviewers:
+ keishi@chromium.org

[tkent, 2016-06-29 01:21:53]

Keishi, would you review this please?

[keishi, 2016-06-29 02:34:53]

LGTM

[tkent, 2016-06-29 03:29:49]

The CQ bit was checked by tkent@chromium.org

[commit-bot: I haz the power, 2016-06-29 03:30:19]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-06-29 04:41:35]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-06-29 04:43:43]

Description was changed from

==========
Improve performance of SELECT element by optimizing Vector.

Replace Vector::clear() with Vector::resize(0) to avoid to deallocate Vector
buffers.

Removing 20,000 OPTIONs: 7,595ms -> 5,779ms

BUG=620142, 624220
==========

to

==========
Improve performance of SELECT element by optimizing Vector.

Replace Vector::clear() with Vector::resize(0) to avoid to deallocate Vector
buffers.

Removing 20,000 OPTIONs: 7,595ms -> 5,779ms

BUG=620142, 624220

Committed: https://crrev.com/8881397e890dd70a187a957ae6910f141d378eb5
Cr-Commit-Position: refs/heads/master@{#402720}
==========

[commit-bot: I haz the power, 2016-06-29 04:43:44]

Patchset 1 (id:??) landed as
https://crrev.com/8881397e890dd70a187a957ae6910f141d378eb5
Cr-Commit-Position: refs/heads/master@{#402720}

[sof, 2016-06-29 05:43:23]

sigbjornf@opera.com changed reviewers:
+ sigbjornf@opera.com

[sof, 2016-06-29 05:43:24]

https://codereview.chromium.org/2105863003/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/html/HTMLSelectElement.cpp (right):

https://codereview.chromium.org/2105863003/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/html/HTMLSelectElement.cpp:803:
m_listItems.resize(0);
Isn't there a risk of m_listItem's backing store never shrinking for a <select/>
with many and then very few <option/>s?

[tkent, 2016-06-29 06:07:46]

https://codereview.chromium.org/2105863003/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/html/HTMLSelectElement.cpp (right):

https://codereview.chromium.org/2105863003/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/html/HTMLSelectElement.cpp:803:
m_listItems.resize(0);
On 2016/06/29 at 05:43:24, sof wrote:
> Isn't there a risk of m_listItem's backing store never shrinking for a
<select/> with many and then very few <option/>s?

There is.
But I guess such scenario is not common.