Re: Why is "git tag --contains" so slow?

From: tytso@mit.edu <tytso@mit.edu>
Date: Jul 2, 2010, 19:26 UTC
Message-ID: <20100702192612.GM1333@thunk.org>
In-Reply-To: <20100701153842.GA15466@sigill.intra.peff.net>

On Thu, Jul 01, 2010 at 11:38:42AM -0400, Jeff King wrote:

Show 8 quoted lines

> 
> Here is a quick and dirty patch to implement what I suggested. With it,
> I get the same results as above, but it runs between 3 and 4 times as
> fast:
> 
>   real    0m0.621s
>   user    0m0.588s
>   sys     0m0.032s

I just tried your patch, and with a large number of tags (198 tags, from v2.6.11 to v2.6.34 with all of the -rc releases of the linux kernel), it is indeed faster: 8.5 seconds without the patch versus 2.3 seconds with the patch.

However, if I remove a large number of tags (since I know this is something that was introduced since 2.6.33, so I made a shared clone of the repository but then I removed all of the tags from 2.6.11 through 2.6.33, so there was only 19 tags in play), the time to execute the git tag --contains became 1.3 seconds without the patch, versus 2.9 seconds without the patch.

So with the oldest tags removed, your patch actually made things run *slower* (2.3 vs 2.9 seconds, which was counter-intuitive to me), and fastest way to speed things up was to restrict the tags that would be searched.

Which gives me the technique I should use to solve my immediate problem, but if the user knows that the patch was merged into mainline within the last 4 months, maybe what would be better is either a way to specify a regexp (or list) of tags that the user finds "interesting" as --contains candidate, or a "--since=4 months" argument.

	   	      	   	      	      - Ted