3

Git submodule seems to be extremely slow on Windows.

To test the performance I created 3 bare repos and committed 3 independent messages to them (no files stored). I then added each of these bare repos as submodules in a new git repo and performed a submodule update and it took over 5 seconds.

git submodule update capture

This seems excessive and very noticeable when using 20+ submodules. What could be causing it to take so long?

Example files: https://drive.google.com/file/d/1n6fAm16tXtt_1YvXbPHhn150iuw-VGOk/view

Run 'git submodule update' inside 'Submodule test'. All submodule URLs in the test are relative.

Running Git version 2.22.0.windows.1 and version 2.23.0.windows.1

Edit:
Tested using regular command line, git bash (as shown), PowerShell and TortoiseGit.

Tested with simplified PATH as suggested by VonC.

matt.baker
  • 232
  • 1
  • 9

1 Answers1

0

Try the same:

See if the issue persists then.

With Git 2.22 (and improved in 2.23), you can measure the performance of a Git command with:

cmd /V /C "set GIT_TRACE2_PERF=C:/Users/me/log.perf&& git submodule update"
or in bash session: 
GIT_TRACE2_PERF=C:/Users/me/log.perf git submodule update
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Thanks for the suggestion. Unfortunately no luck. Git 2.23: same result; Regular CMD: same result; Simplified PATH: same result. Verified the 'set PATH=' took effect using `echo %PATH%` before running. – matt.baker Sep 05 '19 at 06:34
  • @matt.baker My answer was meant to describe one test environment, not three: a CMD with a simplified path and Git 2.23. If this is still slow, that is likely caused by a remote side latency. What is the remote server for those submodules? GitHub? BitBucket? – VonC Sep 05 '19 at 07:10
  • This is all local on the C drive (for testing). No network locations are involved (that I'm aware of). – matt.baker Sep 05 '19 at 07:24
  • @matt.baker Strange, I never experienced such delays. What Windows are you using? And do you have an anti-virus? – VonC Sep 05 '19 at 07:26
  • Windows 10 Version 10.0.18362 Build 18362, but also occurs on mainstream release of Windows 10. I've disabled Windows defender including realtime scanning. For comparison, what times do you get if you use the test setup on your machine? – matt.baker Sep 05 '19 at 07:29
  • @matt.baker Same here, around 3 to 4 seconds per (local) repository submodule indeed. I am checking with the new target2.perfTarget setting: https://stackoverflow.com/a/56094711/6309 – VonC Sep 05 '19 at 07:44
  • @matt.baker `cmd /V /C "set GIT_TRACE2_PERF=C:/Users/me/log.perf&& git submodule update"` or in bash session: `GIT_TRACE2_PERF=C:/Users/me/log.perf git submodule update` – VonC Sep 05 '19 at 08:02
  • @matt.baker I see (for 3 submodules to update) 10 seconds (including the tracingoverhead), with 27 git.exe calls (`ssh-i18n--envsubst`, `rev-parse`, `submodule--helper ` calls). Using a shell script (https://github.com/git/git/blob/master/git-submodule.sh) does not help here. I thought submodule was ported to C (https://github.com/git/git/commit/3604242f080a813d6f20a7394def422d1e55b30e), but that is only `submodule init`. – VonC Sep 05 '19 at 08:10
  • Sorry for the delay. I've run the git trace command with the following result: [log.perf](https://drive.google.com/file/d/1EmTqp3q_WwTi3OxsL0xSHrxbZ0RXV_rM/view) – matt.baker Sep 05 '19 at 12:48
  • @matt.baker Same here, same kind of log. Not sure yet what could be the cause of the slow performance, beside the fact we are using a bash script. – VonC Sep 05 '19 at 12:58
  • This issue looks related: [Checkout is 10 times slower on Windows #1851](https://github.com/git-for-windows/git/issues/1851) – matt.baker Sep 05 '19 at 13:11
  • @matt.baker No quite since it involves parallel jobs and writing files, but any POSIX emulations will slow us down. – VonC Sep 05 '19 at 13:16