Re: git and larger trees, not so fast?

On Thu, 9 Aug 2007, Junio C Hamano wrote:

Btw, I really think it's worth doing even just the hacky patches at this stage, even though it's late in the game for 1.5.3.

That performance problem is serious enough that I'd call it a major bug. Performance has always been one of the goals of git, and when you have a difference between 17s and 0.7s for "git status", that's a *huge* usability thing. It would be sad to release 1.5.3 with a known bug.

[ Some people don't think performance issues are "real bugs", and I think 
  such people shouldn't be allowed to program. ]

Side note: your first patch is actually quite noticeable on even just the kernel. Not nearly as much, but without it, I get about 0.5s, and with it, I get consistently under 0.3s. So it's about a 40% improvement even for smaller projects (and it's probably much more if you have a CPU with a smaller cache: my Core 2 Duo has 4MB of L2 cache, and a lot of the index will even fit in the L1 - a slower CPU with less cache will see a bigger impact, and with smaller repositories, from the unnecessary memory moving).

While 0.5s -> 0.3s may not sound like much, on a slower machine where it might otherwise be 2.5s -> 1.5s, that's likely to be quite noticeable.

In fact, I can tell even on my machine: 0.3s is visible as a "I'm clearly thinking about it" delay (quite frankly, it would be better at 0.1s, which is "immediate"), but 0.5s is already approaching the point where you actually wait for the answer (rather than just notice that it wasn't quite immediate).

				Linus