You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Investigate opportunities to speed up msys2-runtime initialization #32
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:
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 8c01ab4) 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).
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?
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.
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.
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.
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.
Activity
dscho commentedon Mar 12, 2015
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 8c01ab4) 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 commentedon Mar 13, 2015
Further source code inspection shows that there is no
read_mounts_thread(and never was, in Cygwin), likewise theFIXME; // 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 commentedon Mar 13, 2015
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/nullcompletes 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 commentedon Mar 13, 2015
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 commentedon Sep 21, 2015
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 thesaycalls ingit-rebase.sh, though. Are they the same as echo? I've only found stuff about some OS X TTS command online.dscho commentedon Sep 22, 2015
Awesome!
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 ofgit 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.It is a function defined in
git-sh-setup.dscho commentedon Apr 2, 2016
Let's just bury this ticket, it is too broad and vague, anyway.
Merge pull request git-for-windows#32 from derrickstolee/poll