On Sun, Aug 12, 2018 at 10:15:48AM +0200, Nguyễn Thái Ngọc Duy wrote:
> 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
