On Mon, Aug 13, 2018 at 9:25 PM Jeff King <[email protected]> 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
