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

[tytso@mit.edu]

On Thu, Jul 01, 2010 at 11:38:42AM -0400, Jeff King wrote:
> 
> 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