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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
