Running git commands on Debian & Ubuntu on WSL is really slow for large projects

Question

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?

Solution 1

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.

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.

Solution 2

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

Solution 3

• Install git for windows
• Install git on your wsl
• Add this script to your "/usr/local/bin" directory and name it "git": https://gist.github.com/jasonboukheir/3fdab92ece236744528447a4f7f5de00

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.

Solution 4

I ended up adding a hack.

    alias git=git.exe

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

Solution 5

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.

View more solutions

Comments

[nbari]

have you tried git gc and then git status

[MortenMoulder]

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.

[VonC]

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

[MortenMoulder]

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

[VonC]

@MortenMoulder some clues: I/O related (github.com/Microsoft/WSL/issues/2759), or AV (AntiVirus) related: medium.com/@leandrw/…. Or prompt-related (reddit.com/r/bashonubuntuonwindows/comments/7xdrt1/…)

[MortenMoulder]

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.

[VonC]

medium.com/@leandrw/… has a fix: did you test it?

[VonC]

@MortenMoulder I have edited the answer to include the potential causes: 2 out of 3 propose workaround for you to test.

[MortenMoulder]

I don't have any AV related software enabled on my machine.

[VonC]

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

[MortenMoulder]

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.

[VonC]

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

[MortenMoulder]

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.

[VonC]

@MortenMoulder No problem. I'll leave that in my answer for others, who might not have deactivated Windows Defender.

[MortenMoulder]

performance: 0.702618000 s: preload index followed by a performance: 16.311419000 s: refresh index

[MortenMoulder]

Windows Defender is turned off for me :-)

[Yasser Shaikh]

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?

[Berlm]

Thanks a lot! This is exactly what I was looking for

[theblackpearl]

This is great! Made a remarkable difference.

[Chiramisu]

This is similar to what I did. I found this article 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.