Starting from 2.24.0 git status takes twice longer

[DanPristupov]

• I was not able to find an open or closed issue matching what I'm seeing

Setup

• Which version of Git for Windows are you using? Is it 32-bit or 64-bit?

The problem affects both 32-bit and 64-bit versions.

$ git --version --build-options

git version 2.24.1.windows.2
cpu: x86_64
built from commit: 992f0773022527b1b0cb1e0c13aec97dd5248053
sizeof-long: 4
sizeof-size_t: 8

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

$ cmd.exe /c ver

Microsoft Windows [Version 10.0.18362.535]

Details

• Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

Bash

• What commands did you run to trigger this issue?

time git status --porcelain > /dev/null

• What did you expect to occur after running these commands?

I would expect this command to take the same time as in 2.23

• What actually happened instead?

Hello,

Starting from 2.24.0 the git status command takes twice longer. The issue only occurs in the portable git version and still exists in 2.25.0 RC2.

I ensured that the Windows Defender antivirus is not involved, so the problem is not related to (#2426).

I collected some data running time git status --porcelain > /dev/null in different git versions on the same repository

git 2.23.0.windows.1:          0.353s
git 2.24.0.windows.1:          0.630s <-- the problem started there
git 2.24.1.windows.2:          0.730s
git 2.24.1.windows.2 (32-bit): 0.715s
git 2.25.0.rc2.windows.1:      0.780s

git 2.24.1.windows.2 (non-portable): 0.317s <-- non-portable git is still fast

As far as I know the problem can be reproduced with any relatively large repository (e.g. https://github.com/facebook/react/) on any computer.

Is this a bug or an intended behavior? What can I do to help to investigate that issue?

[dscho]

2.24.0.windows.1

This version corresponds to commit 6a3fa2a, and

2.23.0.windows.1

... this version corresponds to commit 4db2e5c. We have snapshots for both at https://wingit.blob.core.windows.net/files/index.html.

To help me help you, could I ask you to bisect a bit further?

[DanPristupov]

Hi,

Looks like the problem has appeared in c25f209

This seems to be strange that the git config change causes the performance regression, but I checked multiple times and it's c25f209 indeed.

- Mon, 4 Nov 2019 07:35:12 +0100 (commit 6a3fa2a1833f3c7ac71cefefe44b3a4b4138e220)
- Sun, 3 Nov 2019 00:23:26 +0100 (commit 44c15909b8e6d701b451851fb64c00fbbfa9fdd0)
- Wed, 30 Oct 2019 11:56:09 +0100 (commit 9356bff6c536a0145c574ecafcd672e49a0763d5)
- Wed, 30 Oct 2019 11:49:06 +0100 (commit cd663ba57979f78f2598ea628b985056f363aba8)
- Wed, 30 Oct 2019 11:44:31 +0100 (commit e96e0b4be65f8c162ebf805bf7267c0563ab91cc)
- Wed, 30 Oct 2019 09:18:45 +0100 (commit 578744fc0ff512f0b1fba93212707b2f8d067b9e)
- Fri, 25 Oct 2019 16:09:52 +0200 (commit d1d8fc26450905cfd36428749bdd6e58330ac0e4)
- Thu, 24 Oct 2019 12:41:28 +0200 (commit b1b9387e59916d870025e95c70dc7603785d4081)
- Fri, 18 Oct 2019 09:06:18 +0200 (commit c25f2092ab56ec4af831c88a1c5c857c6b4d06e6)
+ Thu, 17 Oct 2019 14:12:43 +0200 (commit 144cb183aba9ef2ed1a3b09bca92611e147467f4)
+ Thu, 17 Oct 2019 10:36:57 +0200 (commit b2da288352e8640a35e678df023c934b2f208e23)
+ Mon, 7 Oct 2019 12:06:14 +0200 (commit cd9994f969c5c3c9cf071b4577f026942a359204)
+ Wed, 2 Oct 2019 14:38:02 +0200 (commit d01cfebc01dcf22fa10030860a9a82ffdc0350ed)
+ Mon, 30 Sep 2019 20:21:44 +0200 (commit 8c5225c2594b8002d3d2380d3cdaaa8c0c924614)
+ Tue, 24 Sep 2019 17:33:59 +0200 (commit 89eadabf8039fb815021b8bb000e232cb8a49d23)
+ Mon, 2 Sep 2019 15:08:50 +0200 (commit de7827bd274f5788aaa1b2a1992e45120aa9249b)
+ Mon, 2 Sep 2019 13:53:04 +0200 (commit 94ef49fdd48363589721fd0db64014907d970315)
+ Fri, 23 Aug 2019 16:42:07 +0200 (commit d7ae4d7b27fd5dc334ada4d74e698f9543fe0ae3)
+ Sat, 17 Aug 2019 00:15:16 +0200 (commit 4db2e5cc9e1522131a039cbad3970f147a39f0ce)

[DanPristupov]

OK, I think I found the problem. It looks like the slowness is caused by lack of the core.fscache = true in /etc/gitconfig of the portable git. Is this intentional?

[dscho]

It looks like the slowness is caused by lack of the core.fscache = true in /etc/gitconfig of the portable git. Is this intentional?

Excellent analysis!

FSCache was not intended to be on by default in the Portable Git, basically because the FSCache feature is still somewhat under development and I don't trust it fully. For example, we had problems in the past where FSCache would behave differently from non-FSCache for illegal file names (such as containing colons, which are mistaken for NTFS Alternate Data Streams in non-FSCache mode IIRC).

It is on by default in the installer, so I guess we should switch the default in PortableGit. @DanPristupov how would you feel about changing the default in the script that generates the Portable Git, e.g. right after this line?

[dscho]

how would you feel about changing the default in the script

(And by that, I mean: "open a PR to change the default" 😄 )

[DanPristupov]

Just created the pull request. I made a build on my machine and tested it, everything looks correct. This is my first PR here, please let me know if I missed something.

[dscho]

The next snapshot's Portable Git will have the FSCache turned on by default.