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

From: Jeff King <peff@peff.net>
Date: Nov 17, 2017, 22:12 UTC
Message-ID: <20171117221251.sku6lqbemcddvlky@sigill.intra.peff.net>
In-Reply-To: <CAPu-DQr0eRYiafF64=Mwm56xJgNPH0HVm+B4vKnzK0iAE4_xUg@mail.gmail.com>

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

Show 6 quoted lines

> 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.

Show 5 quoted lines

> 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.

Show 10 quoted lines

> > 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