Re: [PATCH] Reduce performance penalty for turned off traces

On Sun, Nov 12, 2017 at 11:24:11PM +0000, Gennady Kupava wrote:

In reality, gcc didn't do that and I saw 3 function calls. I am pretty
sure that compiler of the distant bright future will do that, and only
problem would be to eliminate that single function call. Hopefully
with -flto it will also eliminate this single functions call, at it
will be able to see through translation units. Given that I actually
like current implementation as it hides all details in .c file.

Yeah, I agree with your analysis that we are really just overriding what
could eventually be figured out by the compiler during LTO.

I do think this is worth pursuing in the meantime, though, because it's
not _too_ much work, and we don't know when that magical optimizing
compiler will appear. :) So this frees us up in the meantime to worry
less about the cost of tracing.

Now, implementation you suggesting moves extra things into .h, so it
is imperfect in terms above, while things I suggested moves only
necessary bit of checking the necessity to do anything, which is only
(interesting) part should be executed while traces are off, and the
only part we really want to be inlined.

I only meant to suggest moving the necessary checking into the .h file.
It's just that we have to make it a static inline for cases where we
don't have variadic macros. Anyway, I'm OK with your original notion of
leaving the non-variadic-macro systems on the "slow" path, so we can
just go with the pure-macro thing you have.

quoted

So it is measurable, and we might expect that tracing a really big loop
(say over all of the objects in the repository) would benefit. OTOH, a
real loop would actually be doing other stuff, so the speedup would be
less dramatic. Still, it seems like an easy win.

I actually quite familiar with performance analysis and know how to
use perf and similar tools a bit -
so if there is something more measurable in TODO, I could try. But I
guess this is interesting to many devs so such tasks probably already
all done and bottlenecks are identified in git =)

There are lots of bottlenecks still to be found, I'm sure. If you want
to have a go at finding some with perf, be my guest. :)

-Peff