<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 17, 2020 at 3:07 PM Wei Mi via Phabricator <<a href="mailto:reviews@reviews.llvm.org">reviews@reviews.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">wmi added a comment.<br>
<br>
In D81981#2099070 <<a href="https://reviews.llvm.org/D81981#2099070" rel="noreferrer" target="_blank">https://reviews.llvm.org/D81981#2099070</a>>, @davidxl wrote:<br>
<br>
> I think it is good to have an entry counter always, so that the profile dump is more readable. Do you have data showing the instrumentation overhead and profile size impact (clang and some large app)?<br>
<br>
<br>
Yes, I tried clang. The instrumentation runtime overhead increases by about 0.8%. The raw profile size increases by 1.8%. The zipped profile size increases by 0.15%.<br>
Right now in the patch, inserting entry counter is guarded by a flag with default value being false.<br>
<br></blockquote><div>How did you test clang. This is for one file or for the whole clang? </div><div>To me, 0.8% is close to nothing.</div><div>My previous patch shows much more than this for a highly threaded program. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Repository:<br>
  rL LLVM<br>
<br>
CHANGES SINCE LAST ACTION<br>
  <a href="https://reviews.llvm.org/D81981/new/" rel="noreferrer" target="_blank">https://reviews.llvm.org/D81981/new/</a><br>
<br>
<a href="https://reviews.llvm.org/D81981" rel="noreferrer" target="_blank">https://reviews.llvm.org/D81981</a><br>
<br>
<br>
<br>
</blockquote></div></div>