git stash is slow on windows
Asked Answered
P

2

54

On my windows machine git stash has about 3.5 seconds overhead on each invocation, which adds about 7 seconds to my git commit hook.

The same command under linux (same machine) takes about 0.01 seconds. The performance issue applies to empty repositories as well.

I have tried the following from this thread and this thread:

  • core.fscache is set to true
  • core.preloadindex is set to true
  • gc.auto is set to 256
  • Setting PS1='$ '
  • Running cmd in administration mode
  • Running inside cmd.exe instead of git-bash

Running GIT_TRACE=true git stash list

16:58:16.844591 git.c:563               trace: exec: 'git-stash' 'list'
16:58:16.844591 run-command.c:336       trace: run_command: 'git-stash' 'list'
16:58:19.699591 git.c:350               trace: built-in: git 'rev-parse' '--git-dir'
16:58:19.859591 git.c:350               trace: built-in: git 'rev-parse' '--git-path' 'objects'
16:58:20.069591 git.c:350               trace: built-in: git 'rev-parse' '--show-toplevel'
16:58:20.154591 git.c:350               trace: built-in: git 'rev-parse' '--git-path' 'index'
16:58:20.244591 git.c:350               trace: built-in: git 'config' '--get-colorbool' 'color.interactive'
16:58:20.334591 git.c:350               trace: built-in: git 'config' '--get-color' 'color.interactive.help' 'red bold'
16:58:20.424591 git.c:350               trace: built-in: git 'config' '--get-color' '' 'reset'
16:58:20.514591 git.c:350               trace: built-in: git 'rev-parse' '--verify' '--quiet' 'refs/stash'

real    0m3.845s
user    0m0.000s
sys     0m0.047s

Running GIT_TRACE_PERFORMANCE=true git stash list

16:59:18.414591 trace.c:420             performance: 0.001078046 s: git command: 'C:\Program Files\Git\mingw64\libexec\git-core\git.exe' 'rev-parse' '--git-dir'                                          
16:59:18.569591 trace.c:420             performance: 0.000947184 s: git command: 'C:\Program Files\Git\mingw64\libexec\git-core\git.exe' 'rev-parse' '--git-path' 'objects'                               
16:59:18.779591 trace.c:420             performance: 0.001253627 s: git command: 'C:\Program Files\Git\mingw64\libexec\git-core\git.exe' 'rev-parse' '--show-toplevel'                                    
16:59:18.869591 trace.c:420             performance: 0.001285517 s: git command: 'C:\Program Files\Git\mingw64\libexec\git-core\git.exe' 'rev-parse' '--git-path' 'index'                                 
16:59:18.955591 trace.c:420             performance: 0.001139994 s: git command: 'C:\Program Files\Git\mingw64\libexec\git-core\git.exe' 'config' '--get-colorbool' 'color.interactive'                   
16:59:19.040591 trace.c:420             performance: 0.001182881 s: git command: 'C:\Program Files\Git\mingw64\libexec\git-core\git.exe' 'config' '--get-color' 'color.interactive.help' 'red bold'       
16:59:19.125591 trace.c:420             performance: 0.001128997 s: git command: 'C:\Program Files\Git\mingw64\libexec\git-core\git.exe' 'config' '--get-color' '' 'reset'                                
16:59:19.215591 trace.c:420             performance: 0.001567766 s: git command: 'C:\Program Files\Git\mingw64\libexec\git-core\git.exe' 'rev-parse' '--verify' '--quiet' 'refs/stash'                    
16:59:19.295591 trace.c:420             performance: 3.730583540 s: git command: 'C:\Program Files\Git\mingw64\bin\git.exe' 'stash' 'list'                                                                

real    0m3.819s                                                                                                                                                                                          
user    0m0.000s                                                                                                                                                                                          
sys     0m0.062s                                                                                                                                                                                          

From the log we see that it takes around 3 seconds between the git-stash command is run and the git-rev-parse is run. Are there any other flags I can run to find the bottleneck?

Parthenopaeus answered 30/5, 2016 at 15:16 Comment(14)
It's possible your repository is big, could you try to launch git gc on your local AND remote repository ?Supralapsarian
It takes the same amount of time in an empty repository. I have updated the question.Parthenopaeus
@Parthenopaeus have you gone through this thread and tested this hintOrtensia
@Ortensia Yes, I have read those threads. They don't seem to work for me. I have updated the question.Parthenopaeus
is the local git repo hosted on your local drive or a remote/network one?Milks
@Milks no, it's hosted on my computerParthenopaeus
Where is the gitconfig file? Isn't it on a remote disk? It should be be in your home directory, but I've seen cases in which this user dir was a remote one, leading to terrible performances.Uniform
If you just want things to work faster, you can try to create a temp branch, commit everything there and you'll have the same effect as if you stashed your changes (I do it like that frequently). But if you asked the question to get a better understanding of how the stash feature works, then you could maybe check the git source code: github.com/git/gitGaytan
I have the same issue as the OP using git-for-windows 2.11.1.windows.1. My gitconfig is on a local SSD, and so is the repository. @MladenB. while it is possible to achieve the same results using branches, it takes several more steps as to make it impractical (as bad or worse than using the slow stash). Besides, the whole point of stash is to not create a commit recorded in history.Shooter
@PascalLeMerrer All other commands (that I've noticed) are reasonably fast. checkout, branch, status, add, commit, and take less than a second to execute. It's just stash that's super slow (15 seconds in my case).Shooter
See github.com/msysgit/git/issues/259. It's dated but closed (msysgit). Someone also opened stackoverflow.com/questions/44159850/… recently.Shooter
Antivirus/Firewall?Force
Relevant: github.com/git/git/pull/495Osborne
Can you try with Git 2.19? (Sept. 2018): git stash is now rewritten in C, even though the script version is still there by default: see my answer below.Selfrealization
S
23

With Git for Windows 2.19 (Sept. 2018), git stash (and git rebase) are no longer script-only, but actually a binary compiled with git.exe.
See git-for-windows/build-extra PR 203.

To activate them, type:

git config --global rebase.useBuiltin true
git config --global stash.useBuiltin true

Warning:

As nice as the speed-ups are, the patches in question are still in flux, and they are not battle-tested at all.

So, for now, the script version of git stash remains the default, that way:

  • users who want the raw speed improvement we got through three Google Summer of Code projects working in parallel can have that,
  • while others who are reluctant to play guinea pig by running only well-tested code can stay on the safe side.

The point remains: in the next versions of Git, the bash script for git-stash will eventually disappear, and its replacement is and will be faster.

Note: that next version will be Git 2.27 (Q2 2020): "git stash" has kept an escape hatch to use the scripted version for a few releases, which got stale.

It has been removed.

See commit 8a2cd3f, commit b0c7362 (03 Mar 2020) by Thomas Gummerer (tgummerer).
(Merged by Junio C Hamano -- gitster -- in commit 369ae75, 27 Mar 2020)

stash: remove the stash.useBuiltin setting

Signed-off-by: Thomas Gummerer

Remove the stash.useBuiltin setting which was added as an escape hatch to disable the builtin version of stash first released with Git 2.22.

Carrying the legacy version is a maintenance burden, and has in fact become out of date failing a test since the 2.23 release, without anyone noticing until now.

So users would be getting a hint to fall back to a potentially buggy version of the tool.

We used to shell out to git config to get the useBuiltin configuration to avoid changing any global state before spawning legacy-stash.
However that is no longer necessary, so just use the 'git_config' function to get the setting instead.

Similar to what we've done in d03ebd411c ("rebase: remove the rebase.useBuiltin setting", 2019-03-18, Git v2.22.0-rc0 -- merge listed in batch #5), where we remove the corresponding setting for rebase, we leave the documentation in place, so people can refer back to it when searching for it online, and so we can refer to it in the commit message.


Update Q2 2019, with Git 2.22, git stash is entirely rewritten in C. ² See commit 40af146, commit 48ee24a, commit ef0f0b4, commit 64fe9c2, commit 1ac528c, commit d553f53, commit d4788af, commit 41e0dd5, commit dc7bd38, commit 130f269, commit bef55dc, commit dac566c, commit ab8ad46 (25 Feb 2019) by Paul-Sebastian Ungureanu (weekly-digest[bot]).
See commit c4de61d, commit 577c199, commit 4e2dd39, commit 8a0fc8d (25 Feb 2019) by Joel Teichroeb (klusark).
See commit 7906af0, commit 90a4627, commit 8d8e9c2 (25 Feb 2019) by Johannes Schindelin (dscho).
(Merged by Junio C Hamano -- gitster -- in commit e36adf7, 22 Apr 2019)

You can still use the shell script with git legacy-stash.

And:

stash: convert stash--helper.c into stash.c

The old shell script git-stash.sh was removed and replaced entirely by builtin/stash.c.
In order to do that, create and push were adapted to work without stash.sh.

For example, before this commit, git stash create called git stash--helper create --message "$*". If it called git stash--helper create "$@", then some of these changes wouldn't have been necessary.

This commit also removes the word helper since now stash is called directly and not by a shell script.

There are optimizations:

stash: optimize get_untracked_files() and check_changes()

This commits introduces a optimization by avoiding calling the same functions again.
For example, git stash push -u would call at some points the following functions:

  • check_changes() (inside do_push_stash())
  • do_create_stash(), which calls: check_changes() and get_untracked_files()

Note that check_changes() also calls get_untracked_files().
So, check_changes() is called 2 times and get_untracked_files() 3 times.

The old function check_changes() now consists of two functions: get_untracked_files() and check_changes_tracked_files().

These are the call chains for push and create:

  • push_stash() -> do_push_stash() -> do_create_stash()
  • create_stash() -> do_create_stash()

To prevent calling the same functions over and over again, check_changes() inside do_create_stash() is now placed in the caller functions (create_stash() and do_push_stash()).
This way check_changes() and get_untracked files() are called only one time.


With Git 2.36 (Q2 2022), removal of the warning "the stash.useBuiltin support has been removed!" is finally done!

See commit e9b272e, commit deeaf5e, commit 5d4dc38, commit 6de0722 (27 Jan 2022) by Johannes Schindelin (dscho).
(Merged by Junio C Hamano -- gitster -- in commit b9f791a, 16 Feb 2022)

stash: stop warning about the obsolete stash.useBuiltin config setting

Signed-off-by: Johannes Schindelin

In 8a2cd3f ("stash: remove the stash.useBuiltin setting", 2020-03-03, Git v2.27.0-rc0 -- merge listed in batch #2), we removed support for stash.useBuiltin, but left a warning in its place.

After almost two years, and several major versions, it is time to remove even that warning.

Selfrealization answered 13/9, 2018 at 16:52 Comment(6)
Thank you! It works fast now. For small changes, it takes about 0.3s on my computer to use the stash.Parthenopaeus
no improvement whatsoever on git version 2.18.0.windows.1Passport
@JerryGoyal But 2.18 seems old. 2.21 is the current version, is able to list commits faster (https://mcmap.net/q/14003/-how-can-i-sort-a-set-of-git-commit-ids-in-topological-order) and has further improvements on rebase (https://mcmap.net/q/14004/-git-rebase-stopped-working-in-git-for-windows)Selfrealization
See also "Git stash on windows extremely slow compared to Libgit2Selfrealization
Does this include git stash push --patch? It's always been glacially slow, especially on large repos, even with pathspec 😶Chondrite
@Chondrite Not sure. Did you test it with Git 2.38+ on both end? And with Scalar activated.Selfrealization
M
3

[update] as mentioned by VonC in his answer:

as of git 2.19 (Sept. 2018), git stash is a built-in command and not an external script anymore.

The following directions do not apply anymore if you are using git 2.19 or later.


git-stash is a script, not a command compiled in the git.exe binary.

On linux : I can find git-stash at /usr/lib/git-core/git-stash - I will let you look for the correct path on windows ...


This script uses #!/bin/sh to run, I don't know what shell implementation is used when you run this on windows.

You can try to run it with another compatible shell (here: bash) :

# the git-core/ dir needs to be in the PATH,
# obviously  you will need to provide the correct path for your git-core dir

$ PATH=/usr/lib/git-core:$PATH bash /usr/lib/git-core/git-stash

You can also turn the -x flag, which will print a trace of all commands executed, and visually check if one of the sub commands seems to be the hanger :

$ PATH=/usr/lib/git-core:$PATH bash -x /usr/lib/git-core/git-stash
Matter answered 7/3, 2017 at 13:4 Comment(1)
on windows sh is bash --posix, AFAIKChondrite

© 2022 - 2024 — McMap. All rights reserved.