28

We have a very large project with almost 15.000 commits total. I run Debian 9.3 on my Windows machine using WSL. My git version is 2.17.0.

When I run commands such as git status, it takes at least 20 seconds to complete. Even if no changes were made.

I have tried multiple older versions of git and even tried Ubuntu, but I still experience the same result. I've tried running a bunch of commands from various posts on here and on other sites, but none of them worked.

Funny thing: When I open up cmd.exe or Git Bash on Windows, it takes less than a second to run git status.

What could be causing this? What can I do to fix this?

MortenMoulder
  • 6,138
  • 11
  • 60
  • 116
  • 1
    have you tried `git gc` and then `git status` – nbari May 18 '18 at 08:04
  • @nbari Yes and it's just as slow. – MortenMoulder May 18 '18 at 08:35
  • what is the output if `which git`? – Tarun Lalwani May 18 '18 at 09:01
  • @TarunLalwani `/usr/bin/git` – MortenMoulder May 18 '18 at 11:43
  • 15000 commits shouldn't be slowing down the stuff, unless maybe if the commited files are really big ones, such as Photoshop projects or picture, or such. However, introduced that way, it sounds much more like a timeout issue somewhere rather than a Git behaviour. Have you checked you CPU load while performing the command ? – Obsidian May 20 '18 at 15:31
  • @Obsidian Yes, Git is using about 14-15% CPU while doing `git status`. – MortenMoulder May 22 '18 at 06:28
  • You can try running [procman](https://learn.microsoft.com/en-us/sysinternals/downloads/procmon) and capture the syscalls of git.exe in WSL vs git bash to narrow down which actions are slow or if there are extra actions. You can filter the process to git.exe and look at the properties of an event to see the duration. – Tony Lee May 25 '18 at 00:54
  • Note: Starting June 2019, WSL 2 is coming: see [my edited answer below](https://stackoverflow.com/a/50415408/6309) – VonC May 06 '19 at 20:49

7 Answers7

16

Update June 2019: WSL 2 is coming, and with it a full system call compatibility.
That should increase Git command performance considerably!

Original answer 2018:

Git is working best when executed on a host without any intermediate layer.

For instance, if your repo is on a shared folder, Git would be considerably slower.
In case of WSL, the repo is locally accessed, but through through a filesystem translation between various Linux file system operations into NT kernel operations.

translation

That would be enough to explain degraded performance, especially on large Git repositories Plus make sure your $PATH does not reference folders with Windows executable that might be called instead of the Linux ones

Possible causes:

  • filesystem emulation (slow): WSL issue 2759
  • Shell Prompt: make sure to test your command in a basic shell prompt, without any complex PS1 computation
  • Windows Defender AV: try and exclude (for testing) the WSL-managed filesystem from AV scan.
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • So what you're essentially saying is, I cannot use Git through WSL? And no, `git` does not interfere with my Windows executable. It's located on my local drive, which is a 500GB Samsung 960 EVO, so it should be plenty fast. Mind you, my other projects with a few hundred commits and files are really fast. – MortenMoulder May 22 '18 at 06:29
  • @MortenMoulder Yes, Git, when used through any layer (network layer, or, here, translation layer), will be slower than when used on bare metal (here Git for Windows, as git.exe, directly in a CMD) – VonC May 22 '18 at 06:41
  • Any clue why it's THAT slow? I know talking to the NT kernel is slower than talking directly to the NT kernel (from the NT kernel), but I find it hard to believe that it's 25-35 times slower (assuming `git.exe status` is 1 second). – MortenMoulder May 22 '18 at 07:06
  • @MortenMoulder some clues: I/O related (https://github.com/Microsoft/WSL/issues/2759), or AV (AntiVirus) related: https://medium.com/@leandrw/speeding-up-wsl-i-o-up-than-5x-fast-saving-a-lot-of-battery-life-cpu-usage-c3537dd03c74. Or prompt-related (https://www.reddit.com/r/bashonubuntuonwindows/comments/7xdrt1/zsh_is_slow_on_wsl_looking_for_fix/) – VonC May 22 '18 at 07:16
  • Doesn't seem like there's a fix and your answer isn't a fix, so I can't accept it as an answer, unfortunately. Thanks for the reply, though. – MortenMoulder May 22 '18 at 07:25
  • https://medium.com/@leandrw/speeding-up-wsl-i-o-up-than-5x-fast-saving-a-lot-of-battery-life-cpu-usage-c3537dd03c74 has a fix: did you test it? – VonC May 22 '18 at 07:25
  • @MortenMoulder I have edited the answer to include the potential causes: 2 out of 3 propose workaround for you to test. – VonC May 22 '18 at 07:28
  • I don't have any AV related software enabled on my machine. – MortenMoulder May 22 '18 at 07:28
  • @MortenMoulder On Windows? Yes you do: Windows Defender, active by default on any recent Windows 10. And for using WSL, you need a recent Windows 10. – VonC May 22 '18 at 07:29
  • As I said: I don't have any AV related software enabled on my machine. I've already disabled all that junk a long time ago. – MortenMoulder May 22 '18 at 07:32
  • @MortenMoulder Windows Defender? Deactivated? This is no "junk", it is the editor's built-in AV, correctly integrated with the kernel. Why would you deactivate that? – VonC May 22 '18 at 07:49
  • Why I would deactivate Windows Defender? I have many reasons, such as because I don't get infected with malware, as I know exactly what I download. Because crypted malware is undetectable on compile and runtime. I can name many more, but let's not discuss why I disable my anti-virus. – MortenMoulder May 22 '18 at 08:00
  • 1
    @MortenMoulder No problem. I'll leave that in my answer for others, who might *not* have deactivated Windows Defender. – VonC May 22 '18 at 08:07
12

I ended up adding a hack.

    alias git=git.exe

Now, it runs windows git executable in WSL with WSL config/SSH settings.

h-rai
  • 3,636
  • 6
  • 52
  • 76
  • Thanks a lot! This is exactly what I was looking for – Berlm Aug 20 '21 at 18:47
  • This is great! Made a remarkable difference. – theblackpearl Sep 15 '21 at 22:22
  • This is similar to what I did. I found this [article](https://markentier.tech/posts/2020/10/faster-git-under-wsl2/#solution) that suggests a function to run the platform-specific command based on the `pwd`. I simply added this function to the end of my `.bashrc` file. _Note: it seems the `which` command lies about the actual executable being used though._ – Chiramisu Mar 04 '22 at 01:18
6

Especially helps me with my oh-my-zsh inside WSL 2 which runs "git status" after every command.

Also turning off Defender like mentioned above helps a little bit.

Jimmy Engelbrecht
  • 653
  • 6
  • 9
  • I created a file named "git" in the mentioned folder, my git status still takes a lot of time, but git.exe is fast. I also went ahead and added random text to that file and saved it, and on running git I do not get any error, when should this script be executed? – Yasser Shaikh Jan 11 '21 at 07:28
  • this is NOT a solution: now `git checkout --patch` complains about missing (windows) perl installation – jonny Aug 29 '23 at 13:16
5

You can have some profiling details by using the GIT_TRACE_PERFORMANCE env var :

$ GIT_TRACE_PERFORMANCE=1 git status -sb -uno
08:51:54.525808 read-cache.c:1889       performance: 0.000330659 s: read cache .git/index
08:51:54.528532 preload-index.c:112     performance: 0.002669928 s: preload index
08:51:54.528667 read-cache.c:1447       performance: 0.000109768 s: refresh index
08:51:54.528892 diff-lib.c:250          performance: 0.000056516 s: diff-files
08:51:54.534630 diff-lib.c:527          performance: 0.005070461 s: diff-index
## wip/foo
08:51:54.536419 trace.c:420             performance: 0.013503141 s: git command: git status -sb -uno
LeGEC
  • 46,477
  • 5
  • 57
  • 104
2

In my WSL with Ubuntu I experience, that the very FIRST "git status" command is much slower than the second one. Probably there is any caching or indexing done at the first run. The second "git status" speed is okay for me.

technergy
  • 259
  • 1
  • 12
2

WSL2

WSL is a funny thing, indeed. git speed in WSL is very related to the filesystem where the files are being read-from/written-to.

Solution:

Make sure you're using git or git.exe depending on the filesystem path.

Add the following snippet at the end of ~/.bashrc (for Bash, ZSH, and friends).

function git() {
  if $(pwd -P | grep -q "^\/mnt\/c\/*"); then
    git.exe "$@"
  else
    command git "$@"
  fi
}

If you're using fish, you can use the following snippet:

function git --wraps git
  if pwd -P | grep -q "^\/mnt\/c\/*"
    git.exe $argv
  else
    command git $argv
  end
end

In my case, although I was working on WSL's filesystem, using the custom git command fixed the problem, looks like there is still a chance for git to do some work outside WSL's filesystem.

Credits to Christoph Grabo (asaaki), who originally posted this solution here.

JesusIniesta
  • 10,412
  • 1
  • 35
  • 28
0

Ran

time git clone https://github.com/git/git.git

and 

time git clone git git.1

on Thinkpad T460s in current WSL, MSYS2 and virtualboxed Fedora 28 (no gui, Putty).

Real times for the local clone were

Fedora 3s, WSL 67s, MSYS2 65s

After switching off Defender, times go down to

WSL 11s, MSYS2 13s

So

  • VirtualBoxed Fedora without GUI is fastest
  • Defender is expensive. Exclude your git working root.
  • found no practical difference if WSL git working directory was under ~ or /c/mnt

Please feel free to repeat the little test.

weberjn
  • 1,840
  • 20
  • 24