[PATCH 1 of 2 v4] localrepo: persistent caching of branch names

Mads Kiilerich mads at kiilerich.com
Fri Oct 17 19:12:22 CDT 2014


On 10/18/2014 12:44 AM, Pierre-Yves David wrote:
> So if the repo is empty, we ensure we write and empty cache file? 
> Seems a bit backward to me.

That is making sure that the cache file always basically matches the 
repo, as far as we cheaply can detect. That seems simple and straight 
forward to me.

Anyway, if there is other comments to v5 I can resend without any cache 
invalidation at all in cache load.

> I'm still concerned about this. I dunno if we should get it in for the 
> freeze and disable if too impactfull or if we should delay that for 
> early 3.2 cycles.

I think the impact so big in a positive way that it is worth taking. 10 
s for a very simple and realistic real world case on a real repo down to 
0.5 s.

>> I understand there are plans/thoughts about moving all cache writing to
>> unlocking / transaction commit. This cache can go there together with
>> the other caches.
>
> Writing on unlock seems a similar amount of work than writing on 
> close. What about we do it too?

Sure. It sounds like that is something that should be in a separate 
follow-up patch anyway and on its own merits.

This caching results of operations done on a localrepo instance during 
its lifetime, and saving when closing it seems like simplest and safest 
solution. A baseline that can be improved later.

>> Other implementations that keep the cache 100% updated all the time can
>> be considered later. This is just a cache and the file format and
>> implementation can be changed.
>
> If you use this for branchmaps, you will ensure it is fully updated at 
> the same time as branchmap and can mostly stick to its update cycle 

Sure. A nice separate feature that can follow later.

/Mads



More information about the Mercurial-devel mailing list