Re: Git performance problems with many tags

Tim Allen [off-list ref] wrote:

However, operations like 'git-fetch' take much, much longer in our
repository than in the kernel repository: a git-fetch that pulls no
updates in the kernel repository takes 1.7s, while our repository
(fetching from one repository to a clone on the same local disk) takes
about 20 seconds. After some experimentation, we discovered that
deleting all the 5557 imported CVS tags made things fast again.

Yes.  git-fetch in the current stable versions is a Bourne shell
script.  Its not very fast as it loops through the refs (tags)
that the two ends have.

There is work in under development (and being tested) that improves
this by converting some of the critical parts to C.

(Interestingly, "git-fetch --no-tags" was not appreciably quicker, while
the tags were still around)

Yes, because that swtich didn't bypass that section of the fetch code
where the slowdown is occuring.

Does git have known scalability problems with large numbers of tags?

Yup.

Is
there anything we can do to mitigate this slowdown, apart from just not
using git's tag feature at all?

Upgrade to the upcoming 1.5.1 release.  Junio recently tagged
1.5.1-rc1.  You can get it by cloning git.git and building the
'master' branch.  It is quite stable.  I would encourage you to
give it a try.

-- 
Shawn.