Re: [PATCH v4 2/5] unpack-trees: add performance tracing

From: Jeff King <peff@peff.net>
Date: Aug 13, 2018, 19:25 UTC
Message-ID: <20180813192526.GC10013@sigill.intra.peff.net>
In-Reply-To: <20180812081551.27927-3-pclouds@gmail.com>

On Sun, Aug 12, 2018 at 10:15:48AM +0200, Nguyễn Thái Ngọc Duy wrote:

Show 18 quoted lines

> We're going to optimize unpack_trees() a bit in the following
> patches. Let's add some tracing to measure how long it takes before
> and after. This is the baseline ("git checkout -" on webkit.git, 275k
> files on worktree)
> 
>     performance: 0.056651714 s:  read cache .git/index
>     performance: 0.183101080 s:  preload index
>     performance: 0.008584433 s:  refresh index
>     performance: 0.633767589 s:   traverse_trees
>     performance: 0.340265448 s:   check_updates
>     performance: 0.381884638 s:   cache_tree_update
>     performance: 1.401562947 s:  unpack_trees
>     performance: 0.338687914 s:  write index, changed mask = 2e
>     performance: 0.411927922 s:    traverse_trees
>     performance: 0.000023335 s:    check_updates
>     performance: 0.423697246 s:   unpack_trees
>     performance: 0.423708360 s:  diff-index
>     performance: 2.559524127 s: git command: git checkout -

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

-Peff