From: Jeff Hostetler <git@jeffhostetler.com>
Date: Tue, 14 Aug 2018 18:19:31 GMT
Subject: Re: [PATCH v4 2/5] unpack-trees: add performance tracing
Message-ID: <90d1bbf7-91a3-74ac-de65-1eb8405dc1f7@jeffhostetler.com>
In-Reply-To: <xmqqk1ot3n4h.fsf@gitster-ct.c.googlers.com>



On 8/13/2018 6:41 PM, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
> 
>> I can buy the argument that it's nice to have some form of profiling
>> that works everywhere, even if it's lowest-common-denominator. I just
>> wonder if we could be investing effort into tooling around existing
>> solutions that will end up more powerful and flexible in the long run.
> 
> Another thing I noticed is that the codepaths we would find
> interesting to annotate with trace_performance_* stuff often
> overlaps with the "slog" thing.  If the latter aims to eventually
> replace GIT_TRACE (and if not, I suspect there is not much point
> adding it in the first place), perhaps we can extend it to also
> cover the need of these trace_performance_* calls, so that we do not
> have to carry three different tracing mechanisms.
> 

I'm looking at adding code to my SLOG (better name suggestions welcome)
patch series to eventually replace the existing git_trace facility.
And I would like to have a set of nested messages like Duy has proposed
be a part of that.

In an independent effort I've found the nested messages being very
helpful in certain contexts.  They are not a replacement for the
various platform tools, like PerfView and friends as discussed earlier
on this thread, but then again I can ask a customer to turn a knob and
run it again and send me the output and hopefully get a rough idea of
the problem -- without having them install a bunch of perf tools.

Jeff