r175906 - Replace some typically large vectors with SmallVector.

[Matthieu Monrocq]

On Fri, Feb 22, 2013 at 10:47 PM, Benjamin Kramer <benny.kra at gmail.com>wrote:

>
> On 22.02.2013, at 22:42, Jordan Rose <jordan_rose at apple.com> wrote:
>
> >
> > On Feb 22, 2013, at 13:40 , Sean Silva <silvas at purdue.edu> wrote:
> >
> >> On Fri, Feb 22, 2013 at 1:29 PM, Benjamin Kramer
> >> <benny.kra at googlemail.com> wrote:
> >>> This may seem counter-intuitive but the POD-like optimization helps
> when the
> >>> vectors grow into multimegabyte buffers. SmallVector calls realloc
> which knows
> >>> how to twiddle virtual memory bits and avoids large copies.
> >>
> >> Is this optimization something that libc++ should be doing?
> >
> > I haven't looked but I would guess that libc++ uses
> is_trivially_movable/is_trivially_copyable instead of is_pod, and all of
> our isPODLike cases should be trivially copyable if not trivially movable.
>
> Yes, our isPODLike is roughly equivalent to is_trivially_copyable (it
> actually uses that type trait as a baseline when compiling with clang). I'm
> not sure if libc++ is allowed to do the optimization, the standard sets
> tighter constraints. SmallVector does the resizing with realloc(3) when the
> type is pod-like (trivially copyable), std::vector uses operator new which
> doesn't have a realloc equivalent.
>
> - Ben
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>

I would rather think that the vector uses the Allocator provided, to obtain
the memory (and the std::allocator just wraps a call to ::operator new).

But the point stands, Allocators do not provide a "reallocate" method, so
there is no choice but allocating another memory blob and transferring the
content.

-- Matthieu.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130223/28191455/attachment.html>