todo
This commit is contained in:
parent
16125694eb
commit
9e9def2dc0
1 changed files with 21 additions and 0 deletions
21
doc/todo/optimise_journal_access.mdwn
Normal file
21
doc/todo/optimise_journal_access.mdwn
Normal file
|
@ -0,0 +1,21 @@
|
||||||
|
Often a command will need to read a number of files from the git-annex
|
||||||
|
branch, and it uses getJournalFile for each to check for any journalled
|
||||||
|
change that has not reached the branch. But typically, the journal is empty
|
||||||
|
and in such a case, that's a lot of time spent trying to open journal files
|
||||||
|
that DNE.
|
||||||
|
|
||||||
|
Profiling eg, `git annex find --in web` shows things called by getJournalFile
|
||||||
|
use around 5% of runtime.
|
||||||
|
|
||||||
|
What if, once at startup, it checked if the journal was entirely empty.
|
||||||
|
If so, it can remember that, and avoid reading journal files.
|
||||||
|
Perhaps paired with staging the journal if it's not empty.
|
||||||
|
|
||||||
|
This could lead to behavior changes in some cases where one command is
|
||||||
|
writing changes and another command used to read them from the journal and
|
||||||
|
may no longer do so. But any such behavior change is of a behavior that
|
||||||
|
used to involve a race; the reader could just as well be ahead of the
|
||||||
|
writer and it would have already behaved as it would after the change.
|
||||||
|
|
||||||
|
But: When a process writes to the journal, it will need to update its state
|
||||||
|
to remember it's no longer empty. --[[Joey]]
|
Loading…
Add table
Add a link
Reference in a new issue