From e8a56e969f38b48f535a97cfad57008f57c0f4aa Mon Sep 17 00:00:00 2001
From: Bobby Holley <bobbyholley@gmail.com>
Date: Fri, 2 Jun 2017 20:02:10 -0700
Subject: [PATCH] Make ParseVec bigger.

MozReview-Commit-ID: DszMC031Xlj
---
 components/selectors/parser.rs | 14 +++++---------
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/components/selectors/parser.rs b/components/selectors/parser.rs
index 3aee478311c..22293688b3a 100644
--- a/components/selectors/parser.rs
+++ b/components/selectors/parser.rs
@@ -932,15 +932,11 @@ fn parse_selector<P, Impl>(parser: &P, input: &mut CssParser) -> Result<Selector
     Ok(selector)
 }
 
-/// We use a SmallVec for parsing to avoid extra reallocs compared to using a Vec
-/// directly. When parsing is done, we convert the SmallVec into a Vec (which is
-/// free if the vec has already spilled to the heap, and more cache-friendly if
-/// it hasn't), and then steal the buffer of that vec into a boxed slice.
-///
-/// If we parse N <= 4 entries, we save no reallocations.
-/// If we parse 4 < N <= 8 entries, we save one reallocation.
-/// If we parse N > 8 entries, we save two reallocations.
-type ParseVec<Impl> = SmallVec<[Component<Impl>; 8]>;
+/// We make this large because the result of parsing a selector is fed into a new
+/// Arc-ed allocation, so any spilled vec would be a wasted allocation. Also,
+/// Components are large enough that we don't have much cache locality benefit
+/// from reserving stack space for fewer of them.
+type ParseVec<Impl> = SmallVec<[Component<Impl>; 32]>;
 
 /// Parses a complex selector, including any pseudo-element.
 ///