Reserve vector capacity when populating vectors in conversion operators

[bdash]

I noticed while looking at some performance profiles today that some of these conversion operators are used on relatively hot codepaths. Reserving capacity before populating them avoids reallocations as they grow and is free performance.

[plafosse]

Very surprising all these were missing. This change should also reduce memory fragmentation which has been a huge cause of memory usage.

[pgoodman]

Related to this change, here is a performance profiling thought I once had:

• Get a baseline profile
• Change the resize policy of vectors to always increase/shrink by exactly the requested size. E.g. push_back allocates a new backing array, one larger than the old array, and copies/moves the data. The same for pop_back.
• Change the reserve policy to be a no-op.
• Get a new profile, with the presumably outsized vector impacts
• Compare profiles to find outsized impacts of vector resizing policies
• Hand-wavy: causal profiling to find the worst-offending vectors

Second profiling ideas:

• For all stack allocated/filled vectors, find the maximum observed size across many test cases
• If the vectors are in functions with loops, then plot the maximum observed loop trip counts
• Figure out reserve policies based on predictability of maximum vector sizes.