avoid reposize database locking overhead when not needed
Only when the preferred content expression being matched uses balanced preferred content is this overhead needed. It might be possible to eliminate the locking entirely. Eg, check the live changes before and after the action and re-run if they are not stable. For now, this is good enough, it avoids existing preferred content getting slow. If balanced preferred content turns out to be too slow to check, that could be tried later.
This commit is contained in:
parent
09955deebe
commit
e006acef22
6 changed files with 43 additions and 12 deletions
|
@ -96,6 +96,8 @@ data MatchFiles a = MatchFiles
|
|||
-- ^ does the matchAction look at information about the key?
|
||||
, matchNeedsLocationLog :: Bool
|
||||
-- ^ does the matchAction look at the location log?
|
||||
, matchNeedsLiveRepoSize :: Bool
|
||||
-- ^ does the matchAction need live repo size information?
|
||||
, matchDesc :: Bool -> MatchDesc
|
||||
-- ^ displayed to the user to describe whether it matched or not
|
||||
}
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue