[PATCH 5 of 5 RFC] obsolete: store obsolete revisions to cache file

[Pierre-Yves David]

On 09/22/2015 10:48 PM, Yuya Nishihara wrote:
> # HG changeset patch
> # User Yuya Nishihara <yuya at tcha.org>
> # Date 1441508842 -32400
> #      Sun Sep 06 12:07:22 2015 +0900
> # Node ID 1e78698ebd6c791fbca9da6bf56b65ef75f21d43
> # Parent  35de00be99c2536643df4e100c7784d39829614b
> obsolete: store obsolete revisions to cache file
>
> This saves ~300msec for the repository that has 83731 markers (8.4MB) in total,
> but has 5404 revisions marked as obsolete (22kB).
>
>    $ time hg log -G -l10 > /dev/null
>    before: 0.474sec
>    after:  0.121sec
>
> We could cache (rev, marker-offset) pair so that uninterested markers can
> be skipped at the parsing state, but it would require further design change.


There is some point I would like to see addressed in the descrition:

- What's the filename (or naming scheme)
- What are actually storing rev? or hash?
- What is the validation strategy and why is it correct.


On this "cache" topic. I was hoping to get a caching structure that 
allow a key to have a growing number of value. It would have multiple 
applications including here. Caching the precursors-rev -> markers 
mapping. Since the keys are dynamic, we can probably use a fixed size 
index + extra data somewhere. With such setup, reading the index would 
give the same information you are trying to cache here. If we cache on 
'rev' it would even give it in O(1) fashion (similar to the current 
branch cache)

I'm not saying we should go for a simpler approach first, but I'm 
brain-dumping these idea here to see if someone get inspired.

-- 
Pierre-Yves David