On Thu, 9 Aug 2007, Junio C Hamano wrote: > > FWIW, moe's script with and without two patches gives these > numbers for me. 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 - 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
