Join Log in
Score:3
code_fodder avatar Ubuntu

Git status is very slow on one PC

do flag
code_fodder

I am not sure if this is an ubuntu issue or a git issue ...

I have two PCs

  • one is an ubuntu VM (call it VM PC)
  • the other is an Ubuntu PC (call it Build PC)

Both are running Ubuntu 18.04.

Both are running on the same hardware (different physical machine - but same hw build).

I have a very large repo structure, but when I run time git submodule foreach --recursive git status I get wildly different times:

  • Build PC: ~40s
  • VM PC: ~9s

If I just do git status on the top level I get ~2s on the Build PC and ~0.5s on the VM PC.

Both are running the same git version 2.17.1 - infact the two Ubuntu's where setup using the same installation scripts - so they are really very similar.

The main difference is that the Build PC has 3 physical 1 NVmem and 2xSSDs:

  1. 256GB OS (NVM)
  2. 1TB sw repos (repo under test is here)
  3. 1TB other repos

Whereas on the VM its all on one SSD within the virutal box disc image (its about 500GB)

I am not sure where to start debugging this issue so I thought I would start in this forum :)

update

I tried this on the OS SSD on the Build PC and still get the slower result.... so its not an issue with the 2nd/3rd SSD or how they are mounted...

Update 2

On the two different machines - they are testing against the same exact repo (cloned in the same way from the same remote). The Build PC one is a more recent clone - but I would hope that the count debug would be the same. Here are the results of: git count-objects -v:

VM PC

count: 281
size: 1184
in-pack: 1698
packs: 2
size-pack: 112961
prune-packable: 0
garbage: 0
size-garbage: 0

Build PC

count: 0
size: 0
in-pack: 1972
packs: 1
size-pack: 112994
prune-packable: 0
garbage: 0
size-garbage: 0

very different values... I am not sure what that means. So I removed and re-cloned the VM PC repo to see if a fresh clone makes a different. Here are those values:

count: 0
size: 0
in-pack: 1972
packs: 1
size-pack: 112994
prune-packable: 0
garbage: 0
size-garbage: 0

I re-ran the git status test and got exactly the same results - where the VM PC was much faster

Update 3

Really oddly running: time GIT_TRACE_PERFORMANCE=1 git st on the Build PC prints a load of debug - but runs as fast as the VM PC (< 1s). But if I run anything else it takes much longer:

  • time GIT_TRACE_PERFORMANCE=1 git st ~0.5s
  • time GIT_TRACE_PERFORMANCE=1 git st 2> /dev/null ~2s
  • time git st ~2s
86
0 + 0
git
uz flag
Jos
Please run `git count-objects -v` on both repos and tell us if they are comparable.
1
Reply
code_fodder avatar
do flag
code_fodder
@jos I ran those tests and updated in the question description above. The numbers came out differently even though they are the same repo. So I removed and re-cloned the VM PC repo (because that was an old clone) and then the numbers where the same. But the times where the same. Curiously I can get the Build PC to run fast if I use `GIT_TRACE_PERFORMANCE` but not if I re-direct the output to /dev/null ... very odd!
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.