Improve performance of SELECT element by optimizing Vector.

third_party/WebKit/Source/core/html/HTMLSelectElement.cpp

Index: third_party/WebKit/Source/core/html/HTMLSelectElement.cpp
diff --git a/third_party/WebKit/Source/core/html/HTMLSelectElement.cpp b/third_party/WebKit/Source/core/html/HTMLSelectElement.cpp
index bafe8c6c7bc0c6610adc5141060677d0811e793d..d92918ec16011df5bacaa829034e9a3027e132af 100644
--- a/third_party/WebKit/Source/core/html/HTMLSelectElement.cpp
+++ b/third_party/WebKit/Source/core/html/HTMLSelectElement.cpp
@@ -651,7 +651,7 @@ void HTMLSelectElement::setActiveSelectionAnchor(HTMLOptionElement* option)
     // 3. Drag the mouse pointer onto the fourth OPTION
     //   m_activeSelectionEndIndex = 3, options at 1-3 indices are selected.
     //   updateListBoxSelection needs to clear selection of the fifth OPTION.
-    m_cachedStateForActiveSelection.clear();
+    m_cachedStateForActiveSelection.resize(0);
     for (auto& element : listItems()) {
         m_cachedStateForActiveSelection.append(isHTMLOptionElement(*element) && toHTMLOptionElement(element)->selected());
     }
@@ -800,7 +800,7 @@ void HTMLSelectElement::setRecalcListItems()
 void HTMLSelectElement::recalcListItems() const
 {
     TRACE_EVENT0("blink", "HTMLSelectElement::recalcListItems");
-    m_listItems.clear();
+    m_listItems.resize(0);

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

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]

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

 
     m_shouldRecalcListItems = false;