ce455223df
Currently this is not an improvement, but it allows for optimising appendJournalFile later. With an optimised appendJournalFile, this will greatly speed up access patterns like git-annex addurl of a lot of urls to the same key, where the log file can grow rather large. Appending rather than re-writing the journal file for each line can save a lot of disk writes. It still has to read the current journal or branch file, to check if it can append to it, and so when the journal file does not exist yet, it can write the old content from the branch to it. Probably the re-reads are better cached by the filesystem than repeated writes. (If the re-reads turn out to keep performance bad, they could be eliminated, at the cost of not being able to compact the log when replacing old information in it. That could be enabled by a switch.) While the immediate need is to affect addurl writes, it was implemented at the level of presence logs, so will also perhaps speed up location logs. The only added overhead is the call to isNewInfo, which only needs to compare ByteStrings. Helping to balance that out, it avoids compactLog when it's able to append. Sponsored-by: Dartmouth College's DANDI project |
||
---|---|---|
.. | ||
Chunk | ||
ContentIdentifier | ||
Difference | ||
Export | ||
MetaData | ||
PreferredContent | ||
Presence | ||
Remote | ||
SingleValue | ||
Trust | ||
Activity.hs | ||
Chunk.hs | ||
Config.hs | ||
ContentIdentifier.hs | ||
Difference.hs | ||
Export.hs | ||
File.hs | ||
FsckResults.hs | ||
Group.hs | ||
Line.hs | ||
Location.hs | ||
MapLog.hs | ||
MetaData.hs | ||
Multicast.hs | ||
NumCopies.hs | ||
PreferredContent.hs | ||
Presence.hs | ||
Remote.hs | ||
RemoteState.hs | ||
Schedule.hs | ||
SingleValue.hs | ||
Smudge.hs | ||
Transfer.hs | ||
Transitions.hs | ||
Trust.hs | ||
Unused.hs | ||
Upgrade.hs | ||
UUID.hs | ||
UUIDBased.hs | ||
View.hs | ||
Web.hs |