Re: [PATCH v4 2/5] unpack-trees: add performance tracing
- From
- Jeff Hostetler <git@jeffhostetler.com>
- Date
- Aug 14, 2018, 18:19 UTC
- 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:
Show 15 quoted lines
> 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