Skip to content

Investigate opportunities to speed up msys2-runtime initialization #32

Closed

Description

@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:

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.

Activity

  1. self-assigned this
    on Mar 8, 2015
  2. dscho commented on Mar 12, 2015

    @dscho
    MemberAuthor

    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).

  3. dscho commented on Mar 13, 2015

    @dscho
    MemberAuthor

    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.

  4. dscho commented on Mar 13, 2015

    @dscho
    MemberAuthor

    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.

  5. dscho commented on Mar 13, 2015

    @dscho
    MemberAuthor

    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.

  6. added this to the Post-release cleanup milestone on Aug 27, 2015
  7. rimrul commented on Sep 21, 2015

    @rimrul
    Member

    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.

  8. dscho commented on Sep 22, 2015

    @dscho
    MemberAuthor

    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.

  9. dscho commented on Apr 2, 2016

    @dscho
    MemberAuthor

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

  10. added a commit that references this issue on Oct 9, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions