<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 29, 2014 at 9:23 AM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@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 id=":895" class="a3s" style="overflow:hidden">Generally I'd suggest skipping emplace_back where push_back will have<br>

the same performance characteristics (since you don't need to call<br>
anything other than the move ctor, which push_back can do just fine)<br>
<br>
But given the use of the small-size optimization, pushing back the<br>
result isn't ideal either, it's probably better to allocate the<br>
element in the Stack then initialize it there so you don't have to<br>
copy the small portion over:<br>
<br>
  // Is there an easy way to make a sequence one larger and return a<br>
reference to that new element? It seems such a common operation...<br>
  Stack.resize(Stack.size() + 1);<br>
  UseListOrder &O = Stack.back();<br>
  ...<br>
<br>
In addition/alternatively, I'm not sure how valuable the small-size<br>
optimization is if all of them are going in another container anyway.<br>
Usually the small optimization is most valuable when it avoids malloc<br>
allocation entirely (by using stack space) but here each element in<br>
Stack will have the small footprint in use - so wasted small buffers<br>
will be costing heap space...<br>
<br>
(Chandler, again - thoughts on this tradeoff? I'm perhaps too readily<br>
open to avoiding premature optimization and thus avoid small-size<br>
optimizations until there's a really good reason to add them, but I<br>
haven't done as much profiling/performance work to have an intuition<br>
about when they're not premature and just good practice)</div></blockquote></div><br></div><div class="gmail_extra">I disagree with the entire patch.</div><div class="gmail_extra"><br></div><div class="gmail_extra">1) We should do this unless its showing up in a profile.</div>
<div class="gmail_extra">2) We shouldn't be rolling our own datastructure here even then. We already have a TinyPtrVector which might be more appropriate *if* this is a critical memory usage problem.</div><div class="gmail_extra">
<br></div><div class="gmail_extra">I tend to agree about the small-size optimization being of dubious use when the container is being moved. I suspect std::vector is the correct datastructure until a profile shows otherwise. If it ever does, the better alternative to this might be to use pooled allocation and array refs.... But I'm skeptical about this being in the profile, and if it is in the profile, that worsens my feelings about the entire approach.</div>
</div>