gitolite performance

TOP TIP: If you have more than 2000 or so repos, then you should be using v3.2 or later; there was a bit of code that went in there that makes a huge difference for really large sites.

tips for performance worriers

Gitolite is pretty efficient in most cases, and generally nothing needs to be done. If you think you have a performance problem, let me know on the mailing list. Meanwhile, here are some tips:

why there's really no need to worry!

In general, gitolite has a constant overhead of about 0.2 seconds on my laptop. There really is nothing to optimise, but you can comment out some triggers as the previous section said.

Here's the big-O stuff:

Gitolite overheads compared to a normal ssh push are:

  1. perl startup time. Fairly constant and fairly small. I have generally found it pretty hard to measure, especially with a hot cache.
  2. rule parse time. Details below
  3. rule interpretation time. Fairly constant, or at least subject to much smaller variations than #2.

"rule parse time" is where it makes a difference. There are 2 files gitolite parses on each "access": ~/.gitolite/conf/ and ~/repositories/your_repo.git/gl-conf. The former contains O(N + M + G*A) lines. In addition, the gl-conf files contains about "A" lines (remember we called it an average), which is negligible.

In practice, you can't measure this at a scale that a developer running a "git push" might even pretend to notice, unless you have more than, say, 5000 repos or so. On my testbed of 11,100 repos, where the is almost 0.7 MB, it takes less than 0.2 seconds to do this.

And on a busy system, when that file will be pretty much always in cache, it's even less.

the only thing that will take more time

Literally, the only thing that will take time is something like "ssh git@host info" because it finds all possible repos and for each of them it tries to check the access. On that same test bed, therefore, this ends up reading all 11,100 "gl-conf" files.

On my laptop this takes about 14 seconds. In contrast, a normal git operation (clone, pull, push, etc) is so small it is hard to measure without software.