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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html