On Mon, Aug 13, 2018 at 9:25 PM Jeff King [off-list ref] wrote:
Am I the only one who feels a little funny about us sprinkling these
performance probes through the code base?
On Linux, "perf" already does a great job of this without having to
modify the source, and there are tools like:
http://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html
that help make sense of the results.
I don't think I have really fully mastered 'perf'. In this case for
example, I don't think the default event 'cycles' is the right one
because we are hit hard by I/O as well. I think at least I now have an
excuse to try that famous flamegraph out ;-) but if you have time to
run a quick analysis of this unpack-trees with 'perf', I'd love to
learn a trick or two from you.
I know that's not going to help on Windows, but presumably there are
hardware-counter based perf tools there, too.
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.
I think part of this sprinkling is to highlight the performance
sensitive spots in the code. And it would be helpful to ask a user to
enable GIT_TRACE_PERFORMANCE to have a quick breakdown when something
is reported slow. I don't care that much about other platforms to be
honest, but perf being largely restricted to root does prevent it from
replacing GIT_TRACE_PERFORMANCE in this case.
--
Duy