Design of persistent tag cache

Greg Ward greg at
Wed Jul 8 21:23:47 CDT 2009

On Wed, Jul 8, 2009 at 1:39 PM, Matt Mackall<mpm at> wrote:
>> Sure, but that's a second-order optimization.  Given the proposed
>> structure of the cache file, we still have to read the whole thing.
>> Comparing tips just means we can test "cacheheads[0] ==
>> currentheads[0]" and possibly skip comparing the whole lists.
> True. But not calling heads can mean the difference between taking .5s
> and .01s.

Ahh!  My current code always calls heads(), so I completely missed
that opportunity to optimize.  Oops.  I'm still going to concentrate
on getting it *working* first, especially with strip and rollback.
Then I'll see about avoiding heads() if possible.

> Yes. I think the most reasonable thing to do here is to use the
> cache to avoid manifest reads of all the still-good heads. Which is
> the same as I'd expect we'd do for changing heads by adding
> csets. I think this can be deferred until tags are actually needed?

I hope so.  You sold me on the idea of invalidating late rather than
early, so I'd like to stick to that.  If nothing else, it keeps
knowledge of tag caching concentrated in one place rather than smeared
all over.

Thanks --


More information about the Mercurial-devel mailing list