<br><br><div class="gmail_quote">On Fri, Feb 22, 2013 at 10:47 PM, Benjamin Kramer <span dir="ltr"><<a href="mailto:benny.kra@gmail.com" target="_blank">benny.kra@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
On 22.02.2013, at 22:42, Jordan Rose <<a href="mailto:jordan_rose@apple.com">jordan_rose@apple.com</a>> wrote:<br>
<br>
><br>
> On Feb 22, 2013, at 13:40 , Sean Silva <<a href="mailto:silvas@purdue.edu">silvas@purdue.edu</a>> wrote:<br>
><br>
>> On Fri, Feb 22, 2013 at 1:29 PM, Benjamin Kramer<br>
>> <<a href="mailto:benny.kra@googlemail.com">benny.kra@googlemail.com</a>> wrote:<br>
>>> This may seem counter-intuitive but the POD-like optimization helps when the<br>
>>> vectors grow into multimegabyte buffers. SmallVector calls realloc which knows<br>
>>> how to twiddle virtual memory bits and avoids large copies.<br>
>><br>
>> Is this optimization something that libc++ should be doing?<br>
><br>
> 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.<br>
<br>
</div>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.<br>

<br>
- Ben<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@cs.uiuc.edu">cfe-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits</a><br>
</div></div></blockquote></div><br>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).<br><br>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.<br>
<br>-- Matthieu.<br>