<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jul 11, 2014 at 12:31 PM, Alp Toker <span dir="ltr"><<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
On 11/07/2014 19:45, Chandler Carruth wrote:<div class=""><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On Fri, Jul 11, 2014 at 7:02 AM, Alp Toker <<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a> <mailto:<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a>>> wrote:<br>
<br>
    Author: alp<br>
    Date: Fri Jul 11 09:02:04 2014<br>
    New Revision: 212816<br>
<br>
    URL: <a href="http://llvm.org/viewvc/llvm-project?rev=212816&view=rev" target="_blank">http://llvm.org/viewvc/llvm-<u></u>project?rev=212816&view=rev</a><br>
    Log:<br>
    raw_svector_ostream: grow and reserve atomically<br>
<br>
    Including the scratch buffer size in the initial reservation<br>
    eliminates the<br>
    subsequent malloc+move operation and offers a healthier constant<br>
    growth with<br>
    less memory wastage.<br>
<br>
<br>
What benchmarks did you run to measure the memory waste, and what were the numbers? I think it is really important to provide these kinds of details with potentially performance impacting changes like this.<br>
</blockquote>
<br></div>
I've been getting some good timings with a synthetic clang syntax-only diagnostics engine stress test (10 runs, Before: 0m3.317s After: 0m3.094s). I can't be sure this is a win for every workload so I've boiled the commit down into a cleanup in r212837.<br>
</blockquote><div><br></div><div>FWIW, I think that's a fairly poor benchmark, even among synthetic benchmarks. The diagnostics stuff is output for the human user, and so there is a low bar past which all speed improvements are unnecessary: the input rate of the human brain, and I think we are already well past that (I like to call this sort of code "human speed" code).<br>
<br>I'm not sure that we really do much string manipulation in the "machine speed" part of the code (i.e. stuff that doesn't have the human brain's input speed as a limit past which there are basically no returns) so I can't suggest a good workload. The only thing I can immediately think of is name mangling in clang.<br>
<br></div><div>-- Sean Silva<br></div><div><br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I'll post my thoughts shortly so we can discuss ideas to resolve that old FIXME:<br>
<br>
raw_svector_ostream::~raw_<u></u>svector_ostream() {<br>
  // FIXME: Prevent resizing during this flush().<br>
  flush();<br>
}<br>
<br>
My secondary interest here is to cook up a seekable raw_svector_ostream so we can run more of the compilation in memory / via API without file descriptors, where raw_fd_ostream is currently required. Beware, patches with even more new ostream subclasses are getting proposed shortly ;-)<span class="HOEnZb"><font color="#888888"><br>

<br>
Alp.</font></span><div class="im HOEnZb"><br>
<br>
-- <br>
<a href="http://www.nuanti.com" target="_blank">http://www.nuanti.com</a><br>
the browser experts<br>
<br></div><div class="HOEnZb"><div class="h5">
______________________________<u></u>_________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/llvm-commits</a><br>
</div></div></blockquote></div><br></div></div>