<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 17, 2014 at 12:27 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="">On 17.03.2014, at 20:10, Pete Cooper <<a href="mailto:peter_cooper@apple.com">peter_cooper@apple.com</a>> wrote:<br>

<br>
><br>
> On Mar 17, 2014, at 11:57 AM, Benjamin Kramer <<a href="mailto:benny.kra@gmail.com">benny.kra@gmail.com</a>> wrote:<br>
><br>
>><br>
>> On 17.03.2014, at 19:47, Pete Cooper <<a href="mailto:peter_cooper@apple.com">peter_cooper@apple.com</a>> wrote:<br>
>><br>
>>> Hi all<br>
>>><br>
>>> Please review this patch to make StringMap be aware of when it contains POD types allocated on a BumpPtrAllocator.  In this case its unnecessary to clear the map in its destructor.  This is particularly painful on IdentiferTable in clang where we walk an 8192 entry map of pointers and uselessly destruct them.<br>

>><br>
>> Ugh. This is really something that the optimizer should do. Have you checked<br>
>> what's preventing LLVM from killing the loop that does nothing?<br>
> I think it’ll do the right thing in terms of the destructors for each element being empty.  The tricky thing is that unless ~StringMap inlines clear(), the resetting of all of the elements to the tombstone key will also still happen, and on a large map that can be really slow.<br>

<br>
</div>In that case, why not just copy the loop into the dtor and remove the zeroing there. Thats only a small amount of duplication and should have the same effect as your isPODLike contraption.</blockquote></div><br>I strongly prefer this approach to more POD-like hackery here.</div>
</div>