blob: dfbba15effdbca000d1704b9d379392badc2b91e (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
|
git-annex does a little bit of work at startup to learn about the git
repository it's running in. That's been optimised some before, but
not entirely eliminated; it's just too useful to have that information
always available inside git-annex. But it turned out that it was doing more work
than needed for many commands, by checking the git config of local remotes.
Thas caused unncessary spin up of removable drives, or automount timeouts,
or generally more work than needed when running commands like `git annex
find` and even tab completing git-annex. That's fixed now, so it
avoids checking the git config of remotes except when running commands that
access some remote.
There's also a new config setting, `remote.<name>.annex-checkuuid` that can
be set to false to defer checking the uuid of local repositories until
git-annex actually uses them. That can avoid even more spinup/automounts,
but that config prevents git-annex from transparently handling the case
where different removable drives get mounted to the same place at different
times.
Speaking of speed, I benchmarked linux kernel mitigation for the meltdown
attack making `git status` 5% slower from a warm cache. It did not
slow down `git annex find` or `git annex find --in remote` enough to be
measured by my benchmark. I expect that git-annex commands that transfer
data are bottlenecked on IO and won't be slowed down appreciably by the
meltdown mitigation either.
Today's work was sponsored by Jake Vosloo on
[Patreon](https://patreon.com/joeyh/).
|
