[PATCH 1 of 2 v4] localrepo: persistent caching of branch names
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
>> 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.
More information about the Mercurial-devel