Design of persistent tag cache
greg at gerg.ca
Wed Jul 8 21:23:47 CDT 2009
On Wed, Jul 8, 2009 at 1:39 PM, Matt Mackall<mpm at selenic.com> 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 ==
>> currentheads" 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
More information about the Mercurial-devel