[LLVMdev] multithreaded performance disaster with -fprofile-instr-generate (contention on profile counters)

[Kostya Serebryany]

>
>
> I can see that the behavior of our current instrumentation is going to be
> a problem for the kinds of applications that you’re looking at. If you can
> find a way to get the overhead down without losing accuracy and without
> hurting the performance for applications without significant contention,
> then we can just adopt that. If you can’t do it without tradeoffs, then we
> should have a separate option to let those who care switch between
> different kinds of instrumentation.
>
So far none of the ideas we discussed can guarantee the same
single-threaded performance, memory consumption and functionality compared
to the current -fprofile-instr-generate.
We'll keep looking for the solution (and continue using AsanCoverage in the
meantime).
I am really surprised that the applications you care about do not have this
issue, but you probably know better :)

--kcc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140424/a16c45cc/attachment.html>