I don't know if this is a git thing, or a git annex thing, but it's weird.
After I add a bunch of files to the annex (and there are many more local files not yet added), git status is slow. That's not really a surprise. It shows the refresh index calculation as usual.
I run it a second time, and I get the exact same result:
% time git status
Refresh index: 100% (2997/2997), done.
<snip>
git status 38.64s user 42.08s system 80% cpu 1:39.95 total
I run it a third time and it's instant.
This happens reliably. Two slow runs, and then a fast run.
I don't love the initial slow run, but it makes sense, so I can live with it. The second slow run doesn't make sense to me though. Is there any way to avoid it? I guess I would expect the first slow run to refresh the index and speed up subsequent runs.
It seems like a similar symptom to git keeps refreshing index.
I am using git and git-annex installed via homebrew on macOS 10.15.7. I have annex.addunlocked set to true.
git version 2.37.0
git-annex version: 10.20220624
build flags: Assistant Webapp Pairing FsEvents TorrentParser MagicMime Feeds Testsuite S3 WebDAV
dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.30 DAV-1.3.4 feed-1.3.2.1 ghc-8.10.7 http-client-0.7.11 persistent-sqlite-2.13.1.0 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.2
key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
operating system: darwin x86_64
supported repository versions: 8 9 10
upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
local repository version: 8
- @pat
Alright I did some reading and experimenting, and it turns out it's the unlocked files. When I use locked files by defaults, git status is as fast as it usually is. I don't fully understand it, but it seems that something about smudging is slow.
Anyway, I can use locked files for most of my stuff, and unlocked files for only active projects.
I don't know why git would re-run the slow operation twice before caching the result for the third time.
But, yes, smudging is slow in repository v8. If you upgrade to v9 it should be significantly faster.