2011/3/22 SZEDER Gábor <szeder@xxxxxxxxxx>: > On Tue, Mar 22, 2011 at 11:28:01AM +0100, Erik Faye-Lund wrote: >> 2011/3/22 SZEDER Gábor <szeder@xxxxxxxxxx>: >> > 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. > > I meant the above only in the context of git, based on my last -- it > seems outdated -- experiences with msysgit about (more than?) a year > ago, when I found such builtins like commit and checkout to be quite > noticeably slow. I'm glad to hear that things are changing for good. Actually, the situation isn't all that good, but it's mostly git-completion.bash's fault: $ time __git_ps1 "%s" build-vbcc real 0m0.162s user 0m0.045s sys 0m0.000s 150+ ms just to assemble what branch you're on does very much makes things feel laggy. This affects even when yo just press enter. This is especially annoying when just doing the meat of it directly is way cheaper: $ time git branch --no-color * master real 0m0.036s user 0m0.016s sys 0m0.000s git commit in itself isn't that bad either: $ time git commit --allow-empty -m. [master 8d8d75e] . real 0m0.051s user 0m0.000s sys 0m0.015s 50 ms for something that actually does something isn't that bad. And if it adds a non-empty commit, it's still OK: $ echo "foo" > test.txt $ git add test.txt warning: LF will be replaced by CRLF in test.txt. The file will have its original line endings in your working directory. $ time git commit -m "bar" [master 641c50e] bar warning: LF will be replaced by CRLF in test.txt. The file will have its original line endings in your working directory. 1 files changed, 1 insertions(+), 0 deletions(-) create mode 100644 test.txt real 0m0.065s user 0m0.015s sys 0m0.015s >> 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. > > The other point of view is that it will cause a regression without a > compensating benefit for maybe more than 75% of the user base ;) > I don't think a minor regression like not getting bash-completion automatically updated (something that only affects interactive use after adding a new alias, and probably also could be fixed by adding a /tmp/git-completion.dirty.shell-pid file or something) should justify degrading performance for an as large portion of users as the Windows users are. (Warning: speculation ahead) Also, I suspect the numbers of Windows developers are underrepresented, for two reasons; - I suspect that Windows developers are less likely to be subscribed to the mailing lists where the Git User Survey are promoted. - I suspect that most Windows users use EITHER Cygwin OR MinGW, but I intentionally picked the largest of the Windows categories instead of adding them up because the Git User Survey allowed people to answer both MinGW and Cygwin. User Survey people, if your read this: please have a separate operating system question next year. It's very valuable information! -- 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