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

[Yuya Nishihara]

On Tue, 29 Sep 2015 17:04:04 -0500, Matt Mackall wrote:
> On Fri, 2015-09-25 at 00:10 +0900, Yuya Nishihara wrote:
> > On Wed, 23 Sep 2015 01:40:12 -0700, Pierre-Yves David wrote:
> > > 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)
> > 
> > "cache/obsrevs-{'b'ig or 'l'ittle}{version}"
> > 
> > It has endian flag in case a repository is shared across Power and x86
> > machines. version isn't important.
> 
> I'd prefer to always store big-endian. Endian-conversion is cheap and
> intentionally choosing big-endian means we're slightly more likely to
> get portability right when developing on x86 because we eliminate the
> write-native-read-big or write-big-read-native cases without needing to
> test on ARM/etc.

Hmm, makes sense. Endian-conversion won't be slower than creating a Python
int. Also, x86 provides bswap instruction if we really need it.

OT: ARM is typically used in little-endian mode. I think well-known big-
endian microprocessor is Atmel AVR?