mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
git-annex/Types/BranchState.hs

33 lines
1,010 B
Haskell
Raw Normal View History

Branch handling improvements Support creating the branch. Unified branch state into a single data type. Only commit changes when the index has been changed.
2011-06-22 19:58:30 +00:00
{- git-annex BranchState data type
-
add back git-annex branch read cache The cache was removed way back in 2012, commit 3417c55189275d038bc445fe3ef71090d518e79e Then I forgot I had removed it! I remember clearly multiple times when I thought, "this reads the same data twice, but the cache will avoid that being very expensive". The reason it was removed was it messed up the assistant noticing when other processes made changes. That same kind of problem has recently been addressed when adding the optimisation to avoid reading the journal unnecessarily. Indeed, enableInteractiveJournalAccess is run in just the right places, so can just piggyback on it to know when it's not safe to use the cache.
2020-07-06 16:09:53 +00:00
- Copyright 2011-2020 Joey Hess <id@joeyh.name>
Branch handling improvements Support creating the branch. Unified branch state into a single data type. Only commit changes when the index has been changed.
2011-06-22 19:58:30 +00:00
-
update licenses from GPL to AGPL This does not change the overall license of the git-annex program, which was already AGPL due to a number of sources files being AGPL already. Legally speaking, I'm adding a new license under which these files are now available; I already released their current contents under the GPL license. Now they're dual licensed GPL and AGPL. However, I intend for all my future changes to these files to only be released under the AGPL license, and I won't be tracking the dual licensing status, so I'm simply changing the license statement to say it's AGPL. (In some cases, others wrote parts of the code of a file and released it under the GPL; but in all cases I have contributed a significant portion of the code in each file and it's that code that is getting the AGPL license; the GPL license of other contributors allows combining with AGPL code.)
2019-03-13 19:48:14 +00:00
- Licensed under the GNU AGPL version 3 or higher.
Branch handling improvements Support creating the branch. Unified branch state into a single data type. Only commit changes when the index has been changed.
2011-06-22 19:58:30 +00:00
-}
module Types.BranchState where
add back git-annex branch read cache The cache was removed way back in 2012, commit 3417c55189275d038bc445fe3ef71090d518e79e Then I forgot I had removed it! I remember clearly multiple times when I thought, "this reads the same data twice, but the cache will avoid that being very expensive". The reason it was removed was it messed up the assistant noticing when other processes made changes. That same kind of problem has recently been addressed when adding the optimisation to avoid reading the journal unnecessarily. Indeed, enableInteractiveJournalAccess is run in just the right places, so can just piggyback on it to know when it's not safe to use the cache.
2020-07-06 16:09:53 +00:00
import Common
import qualified Data.ByteString.Lazy as L
remove unused fields
2012-12-20 03:41:54 +00:00
data BranchState = BranchState
Sped up query commands that read the git-annex branch by around 5% The only price paid is one additional MVar read per write to the journal. Presumably writing a journal file dominiates over a MVar read time by several orders of magnitude. --batch does not get the speedup because then it needs to notice when another process has made a change. Also made the assistant and other damon modes bypass the optimisation, which would not help them anyway.
2020-04-09 17:54:43 +00:00
{ branchUpdated :: Bool
-- ^ has the branch been updated this run?
, indexChecked :: Bool
-- ^ has the index file been checked to exist?
, journalIgnorable :: Bool
-- ^ can reading the journal be skipped, while still getting
-- sufficiently up-to-date information from the branch?
cache one more log file for metadata My worry was that a preferred content expression that matches on metadata would have removed the location log from cache, causing an expensive re-read when a Seek action later checked the location log. Especially when the --all optimisation in the previous commit pre-cached the location log. This also means that the --all optimisation could cache the metadata log too, if it wanted too, but not currently done. The cache is a list, with the most recently accessed file first. That optimises it for the common case of reading the same file twice, eg a get, examine, followed by set reads it twice. And sync --content reads the location log 3 times in a row commonly. But, as a list, it should not be made to be too long. I thought about expanding it to 5 items, but that seemed unlikely to be a win commonly enough to outweigh the extra time spent checking the cache. Clearly there could be some further benchmarking and tuning here.
2020-07-07 18:18:55 +00:00
, cachedFileContents :: [(RawFilePath, L.ByteString)]
-- ^ contents of a few files recently read from the branch
add back git-annex branch read cache The cache was removed way back in 2012, commit 3417c55189275d038bc445fe3ef71090d518e79e Then I forgot I had removed it! I remember clearly multiple times when I thought, "this reads the same data twice, but the cache will avoid that being very expensive". The reason it was removed was it messed up the assistant noticing when other processes made changes. That same kind of problem has recently been addressed when adding the optimisation to avoid reading the journal unnecessarily. Indeed, enableInteractiveJournalAccess is run in just the right places, so can just piggyback on it to know when it's not safe to use the cache.
2020-07-06 16:09:53 +00:00
, needInteractiveAccess :: Bool
-- ^ do new changes written to the journal or branch by another
-- process need to be noticed while the current process is running?
-- (This makes the journal always be read, and avoids using the
-- cache.)
remove unused fields
2012-12-20 03:41:54 +00:00
}
Branch handling improvements Support creating the branch. Unified branch state into a single data type. Only commit changes when the index has been changed.
2011-06-22 19:58:30 +00:00
startBranchState :: BranchState
cache one more log file for metadata My worry was that a preferred content expression that matches on metadata would have removed the location log from cache, causing an expensive re-read when a Seek action later checked the location log. Especially when the --all optimisation in the previous commit pre-cached the location log. This also means that the --all optimisation could cache the metadata log too, if it wanted too, but not currently done. The cache is a list, with the most recently accessed file first. That optimises it for the common case of reading the same file twice, eg a get, examine, followed by set reads it twice. And sync --content reads the location log 3 times in a row commonly. But, as a list, it should not be made to be too long. I thought about expanding it to 5 items, but that seemed unlikely to be a win commonly enough to outweigh the extra time spent checking the cache. Clearly there could be some further benchmarking and tuning here.
2020-07-07 18:18:55 +00:00
startBranchState = BranchState False False False [] False
Reference in a new issue Copy permalink