Re: Poor performance of git describe in big repos

[Jeff King <peff@peff.net>]

On Mon, Jun 03, 2013 at 09:39:21AM +0100, Alex Bennée wrote:

> > in the target repository. You can check that it's working because "git
> > rev-list --all --count" should be an order of magnitude faster. You may
> > need to add "save_commit_buffer = 0" in any commands you are checking,
> > though, as the optimization can only kick in if parse_commit does not
> > want to save the buffer as a side effect.
> 
> Is this a command line argument? The tools don't seem to think so.

If you mean the "save_commit_buffer = 0", no; I mean you would have to
insert it somewhere in builtin/$CMD.c, and then recompile. However,
git-describe already has it, so it should work.

> Anyway it seems to make a marginal difference to my case:

I get much better results:

  $ cd linux-2.6
  $ time git --no-pager describe --long --tags HEAD~800
  v3.5-6956-gaa0b3b2

  real    0m0.261s
  user    0m0.248s
  sys     0m0.012s

  $ git metapack --commits --all
  $ time git --no-pager describe --long --tags HEAD~800
  v3.5-6956-gaa0b3b2

  real    0m0.057s
  user    0m0.032s
  sys     0m0.024s

which implies that your time is being spent elsewhere. That topic
wouldn't avoid inflating tag objects from disk. Do you have really big
tag objects (or unannotated tags pointing to blobs)? What does:

  git for-each-ref --format='%(object)' refs/tags |
  git cat-file --batch-check |
  sort -k 3nr |
  head

say?

-Peff