Re: [PATCH v8 2/3] p0006-read-tree-checkout: perf test to time read-tree

From: Jeff King <peff@peff.net>
Date: Apr 10, 2017, 21:21 UTC
Message-ID: <20170410212142.zc3tsnirjcuoewmw@sigill.intra.peff.net>
In-Reply-To: <20170410211403.25126-3-git@jeffhostetler.com>

On Mon, Apr 10, 2017 at 09:14:02PM +0000, git@jeffhostetler.com wrote:

> From: Jeff Hostetler <jeffhost@microsoft.com>
> 
> Created t/perf/repos/many-files.sh to generate large, but
> artificial repositories.

I think this is a good direction. In the long run we might want some kind of magic to pull from the "library" of repos when running perf tests, but it's not a big deal to run the script manually and point GIT_PERF_REPO at the result.

As a bonus, this should be faster when running perf tests, since we can reuse the built repo when testing each version of Git.

Show 16 quoted lines

> +## This test measures the performance of various read-tree
> +## and checkout operations.  It is primarily interested in
> +## the algorithmic costs of index operations and recursive
> +## tree traversal -- and NOT disk I/O on thousands of files.
> +## Therefore, it uses sparse-checkout to avoid populating
> +## the ballast files.
> +##
> +## It expects the test repo to have certain characteristics.
> +## Branches:
> +## () master        := an arbitrary commit.
> +## () ballast       := an arbitrary commit with a large number
> +##                     of changes relative to "master".
> +## () ballast-alias := a branch pointing to the same commit
> +##                     as "ballast".
> +## () ballast-1     := a commit with a 1 file difference from
> +##                     "ballast".

I'm OK with leaving these requirements on the repo in the name of simplicity, though it does make it harder to perf-test against a regular repo.

I wonder if we could make reasonable guesses, like:

  master => HEAD
  ballast => $(git rev-list HEAD | tail -n 1)
  ballast-alias => git branch $ballast
  ballast-1 => HEAD^

That would approximate your conditions in a real-world repository, and it should be easy to make your synthetic one fit the bill exactly.

I don't know if you'd want to turn on sparse checkout manually or not when testing a real-world repo.

-Peff