[llvm-dev] RFC: [SmallVector] Adding SVec<T> and Vec<T> convenience wrappers.
Duncan P. N. Exon Smith via llvm-dev
llvm-dev at lists.llvm.org
Mon Nov 30 17:44:36 PST 2020
> On 2020 Nov 27, at 20:45, Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>
> Sorry for falling off the map on this thread:
>
> On Nov 17, 2020, at 1:42 PM, David Blaikie <dblaikie at gmail.com <mailto:dblaikie at gmail.com>> wrote:
>>> Thoughts/suggestions:
>>> - Adding the default seems very reasonable to me, and I think that 64 bytes is a good default. I think you should change the behavior so that SmallVector<LargeThing> defaults to a single inline element instead of zero though. Perhaps generate a static_assert when it is crazy large.
>>
>> Out of curiosity: Why a single rather than zero?
>
> My rationale for this is basically that SmallVector is typically used for the case when you want to avoid an out-of-line allocation for a small number of elements, this was the reason it was created. While there is some performance benefits of SmallVector<T,0> over std::vector<> they are almost trivial.
The performance benefits aren't trivial.
std::vector grow operations will refuse to use std::move for some T, a pessimization required by its exception guarantees, even if you're building with `-fno-exceptions`. We had a massive compile-time problem in 2016 related to this that I fixed with 3c406c2da52302eb5cced431373f240b9c037841 by switching to SmallVector<T,0>. You can see the history in r338071 / 0f81faed05c3c7c1fbaf6af402411c99d715cf56.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201130/96d8044e/attachment.html>
More information about the llvm-dev
mailing list