Investigate opportunities to speed up msys2-runtime initialization

[dscho]

With the msysGit-based Git for Windows, we benefitted from a bunch of patches to the MSys1 runtime, designed to speed up the initialization in the common case – when the Bash was started from within Git:

• https://github.com/msysgit/msysgit/blob/msys/src/rt/patches/0008-Do-not-start-the-fstab-observer-thread.patch
• https://github.com/msysgit/msysgit/blob/msys/src/rt/patches/0009-spawning-of-processes-combine-for-loops-and-resolve-.patch
• https://github.com/msysgit/msysgit/blob/msys/src/rt/patches/0011-msys.dll-Don-t-pull-user32.dll-friends-just-to-detec.patch
• https://github.com/msysgit/msysgit/blob/msys/src/rt/patches/0012-bash-Don-t-load-user32.dll-for-every-shell-process.patch

We need to figure out how/if we can forward port those patches, to bring back a little speed to Git for Windows even after the switch to MSys2.

[dscho]

From a (hardly scientific) test, it seems there is not much we can gain at the moment: when running t3404 – one of the most shell-intensive tests which passes within 55 seconds on this here developer's puny old MacBook – msysGit-based Git (built from 8c01ab42cc7a1d6cff70115d845c5f91b7ce8684) takes 11 minutes 18 seconds in the Windows Azure VM while MSys2-based Git takes 11 minutes 45 seconds.

That is not a big difference. Between msysGit and MSys2, that is.

Our efforts to speed up Git might be better directed to turning more parts of Git into proper builtins (we will have to convince upstream with hard numbers – those should be really easy to come by – that it is necessary to do that, even though there is not yet much willingness to acknowledge the need).

[dscho]

Further source code inspection shows that there is no read_mounts_thread (and never was, in Cygwin), likewise the FIXME; // Is the below loop necessary?

This patch still needs porting, though: https://github.com/msysgit/msysgit/blob/msys/src/rt/patches/0011-msys.dll-Don-t-pull-user32.dll-friends-just-to-detec.patch (but most likely needs to be made opt-in so that upstream MSys2 will accept the change).

And for the bash, I could imagine that https://github.com/msysgit/msysgit/blob/msys/src/rt/patches/0012-bash-Don-t-load-user32.dll-for-every-shell-process.patch would still apply, too.

[dscho]

And for the bash, I could imagine that https://github.com/msysgit/msysgit/blob/msys/src/rt/patches/0012-bash-Don-t-load-user32.dll-for-every-shell-process.patch would still apply, too.

It almost applies, but that was easy enough to patch. The big problem is that there is no measurable speed-up at all. With both patched and unpatched Bash, the ./configure --help >/dev/null completes in just over one second here, stabilizing around 1.07 seconds. The really curious thing is that using msysGit's Bash, it takes longer, roughly 1.5 seconds!

Therefore I will abandon this approach and rather focus on the hints in the commit message to try to find some other way to accelerate the startup.

[dscho]

A couple more tests later, I figure that this ticket is not crucial for the upcoming Git for Windows release: there might be room for improvement, but performance at the moment is on par with msysGit's MSys1 runtime, sometimes even better.

[rimrul]

Our efforts to speed up Git might be better directed to turning more parts of Git into proper builtins (we will have to convince upstream with hard numbers – those should be really easy to come by – that it is necessary to do that, even though there is not yet much willingness to acknowledge the need).

I'm willing to work on this. I guess I'll have to convert them into builtins one command at a time and submit the changes upstream with measured speed differences in the corresponding unit tests. I might need your help preparing the first commit(s) for upstream submission and the arguments why we feel a need for this, to convince the mailing list. I thought about starting with git-stash since I commonly use the stash command, but I could also start with rebase since that would probably speed up t3404. I'm not sure about the say calls in git-rebase.sh, though. Are they the same as echo? I've only found stuff about some OS X TTS command online.

[dscho]

I'm willing to work on [converting scripts to builtins].

Awesome!

I thought about starting with git-stash since I commonly use the stash command

That makes a lot of sense. Working on something you use yourself is always the most rewarding option.

The way I would suggest to go forward is to start implementing a stash--helper (in the same spirit as the bisect--helper): a little builtin that implements just one function of git stash, e.g. the core part of the non-patch stashing. Once that builtin compiles, these lines can be substituted by a call to the helper. Those would already be two commits, of course. Or even three: one to introduce the helper, one to reimplement the shell commands, and one to substitute the shell commands by one single call to the helper.

Once that works, another few lines of the script can be converted into a builtin. Incrementally, this will eventually become the builtin git stash.

I'm not sure about the say calls in git-rebase.sh

It is a function defined in git-sh-setup.

[dscho]

Let's just bury this ticket, it is too broad and vague, anyway.