<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 28, 2016 at 4:23 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This is the idea we chatted today to try to avoid mallocs os windows.<br>
I was surprised to find this a small speedup up on linux</blockquote><div><br></div><div>The numbers you show below indicate a 0.07% difference in performance. It is somewhat spurious to call that "small". More like "negligible".</div><div><br></div><div>To put some numbers on this, CPU's will clock differently depending on the number of cores available. With only one core being used, they may be at their fastest clock, while if two cores are being used they will clock down by, say, 20% (and even more if more CPU's are being used).</div><div><br></div><div>Assuming that LTO speed is linearly proportional to the clock frequency, then 0.07% performance difference corresponds to a difference of 0.4% in time spent at the highest clock frequency (in absolute terms, this is about 100ms out of a 30s LTO run). E.g. you may have touched the mouse during one run and not the other or you refreshed gmail in one run but not the other.</div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> (with /tmp in<br>
tmpfs), so I wonder if we are doing something funny in SmallVector.<br>
<br>
Linking llvm-as I got<br>
<br>
master: 29.774786873 seconds<br>
patch 29.752283093 seconds<br>
<br>
Could one of you benchmark this on windows? If it is a performance win<br>
there too I will clean the patch up and send for proper review.<br>
<br>
Cheers,<br>
Rafael<br>
</blockquote></div><br></div></div>