2011/3/22 SZEDER Gábor <szeder@xxxxxxxxxx>: > On Tue, Mar 22, 2011 at 10:16:16AM +0100, Erik Faye-Lund wrote: >> 2011/3/22 SZEDER Gábor <szeder@xxxxxxxxxx>: >> > On Tue, Mar 22, 2011 at 12:53:43AM -0700, Junio C Hamano wrote: >> >> This is a constructive tangent but if we are going to run $(__git_aliases) >> >> every time we run _git_help, perhaps it would want a hack similar to the >> >> way the value for $__git_all_commands is generated just once? >> > >> > I think this is not necessary. We already run __git_aliases() every >> > time after 'git <TAB>', and it was not an issue so far. And indeed, I >> > just created 50 aliases, and the time required for __git_aliases() >> > seems to be negligible: >> > >> > $ time __git_aliases >> > <bunch of aliases> >> > >> > real 0m0.028s >> > user 0m0.016s >> > sys 0m0.004s >> > >> >> Unfortunately, the situation is not quite so good on Windows: >> $ time __git_aliases >> <bunch of aliases> >> >> real 0m0.112s >> user 0m0.030s >> sys 0m0.015s >> >> This is with 50 aliases, with 0 aliases I get this: >> $ time __git_aliases >> test >> >> real 0m0.063s >> user 0m0.015s >> sys 0m0.015s > > I see. However, on Windows everything git-related tends to be slow, > so this is nothing new. That's not the case. Every thing Git-related isn't slow on Windows, but there are some things in Git that is. > The question is whether the slowness of a known slow platform would > justify the regression on all platforms. > Windows isn't slow. Get over this way of thinking, it's just wrong. Windows has some different performance characteristics for some operations than e.g Linux, but saying that it's slow is just wrong. However, _Bash for Windows_ is quite slow, much due to Windows' lack of fork(), which means that some very involved emulation needs to be performed. But even so, at least 25% of the git user base is on Windows, according to the latest Git User Survey. That makes this stuff matter. -- 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