comments
This commit is contained in:
parent
c3993a2655
commit
6cb9113ff5
2 changed files with 55 additions and 0 deletions
|
@ -0,0 +1,33 @@
|
||||||
|
[[!comment format=mdwn
|
||||||
|
username="joey"
|
||||||
|
subject="""comment 16"""
|
||||||
|
date="2021-06-08T20:56:50Z"
|
||||||
|
content="""
|
||||||
|
This is starting to make some sense. If you're running git-annex add
|
||||||
|
N times adding M files each time, then each run will now diff the
|
||||||
|
changes in the index made by the previous run.
|
||||||
|
|
||||||
|
And the first part of diffing the index is generating a tree from all the
|
||||||
|
files in it, which is to some extent `O(N*M)` (though IDK, git may have
|
||||||
|
optimisations involving subtrees or such). So the combined N git-annex add
|
||||||
|
runs come to `O(N*N*M)`
|
||||||
|
|
||||||
|
On linux, `git write-tree` with 100,000 files in the index runs in under 1
|
||||||
|
second, so athe `N*M` is not too bad. And then there's the overhead of
|
||||||
|
git-annex processing the resulting diff, which takes more time but is what
|
||||||
|
I've been optimising.
|
||||||
|
|
||||||
|
Perhaps on OSX something is making the write-tree significantly slower.
|
||||||
|
Or something is making it run the command more with fewer files per run.
|
||||||
|
Although IIRC OSX has close to the same maximum command line length as
|
||||||
|
linux.
|
||||||
|
|
||||||
|
Or maybe the index diffing is diffing from the wrong start point.
|
||||||
|
One way I can think of where this would happen is if
|
||||||
|
it somehow misdetects the index as being locked.
|
||||||
|
|
||||||
|
A --debug trace of the one of the later git-annex add runs in that
|
||||||
|
test case would probably shed some useful light.
|
||||||
|
|
||||||
|
Yes, --batch should avoid the problem...
|
||||||
|
"""]]
|
|
@ -0,0 +1,22 @@
|
||||||
|
[[!comment format=mdwn
|
||||||
|
username="joey"
|
||||||
|
subject="""comment 2"""
|
||||||
|
date="2021-06-08T16:03:13Z"
|
||||||
|
content="""
|
||||||
|
I tried making reconcileStaged display the message itself, this is the
|
||||||
|
result:
|
||||||
|
|
||||||
|
add foo
|
||||||
|
100% 30 B 73 KiB/s 0s(scanning for annexed files...)
|
||||||
|
ok
|
||||||
|
|
||||||
|
So for that to be done, showSideAction would need to clear the progress
|
||||||
|
bar display first. Note that the display is ok when concurrent output is
|
||||||
|
enabled:
|
||||||
|
|
||||||
|
add c (scanning for annexed files...)
|
||||||
|
ok
|
||||||
|
|
||||||
|
Ok.. Fixed that display glitch, and made reconcileStaged display
|
||||||
|
the message itself when it's taking a while to run.
|
||||||
|
"""]]
|
Loading…
Add table
Add a link
Reference in a new issue