Re: cherry-pick very slow on big repository

From: Jeff King <peff@peff.net>
Date: Nov 10, 2017, 10:20 UTC
Message-ID: <20171110102011.yqtka6a3wmgcvkl6@sigill.intra.peff.net>
In-Reply-To: <alpine.DEB.2.00.1711100959300.2391@ds9.cixit.se>

On Fri, Nov 10, 2017 at 10:39:39AM +0100, Peter Krefting wrote:

Show 7 quoted lines

> Running strace, it seems like it is doing lstat(), open(), mmap(), close()
> and munmap() on every single file in the repository, which takes a lot of
> time.
> 
> I thought it was just updating the status, but "git status" returns
> immediately, while cherry-picking takes several minutes for every
> cherry-pick I do.

It kind of sounds like a temporary index is being refreshed that doesn't have the proper stat information.

Can you get a backtrace? I'd do something like:

  - gdb --args git cherry-pick ...
  - 'r' to run
  - give it a few seconds to hit the CPU heavy part, then ^C
  - 'bt' to generate the backtrace

which should give a sense of which code path is leading to the slowdown (or of course use real profiling tools, but if the slow path is taking 6 minutes, you'll be likely to stop in the middle of it ;) ).

-Peff