[PATCH 4 of 6 frozen-repos] localrepo: ability to obtain a read-only snapshot of a repo

[Gregory Szorc]

On Sun, Nov 22, 2015 at 9:23 PM, Pierre-Yves David <
pierre-yves.david at ens-lyon.org> wrote:

>
>
> On 11/21/2015 05:14 PM, Gregory Szorc wrote:
>
>> # HG changeset patch
>> # User Gregory Szorc <gregory.szorc at gmail.com>
>> # Date 1448154001 28800
>> #      Sat Nov 21 17:00:01 2015 -0800
>> # Node ID 888c2171adffa8340406b50aae02375f7bef50f4
>> # Parent  f559e16232491e44fc4dac6c12872cb2e9164d27
>> localrepo: ability to obtain a read-only snapshot of a repo
>>
>> As part of performing some performance profiling, I noticed that a lot
>> of time can be spent resolving repoview.changelog (the changelog must
>> be resolved when performing repo[x] for example). The reason is that
>> the changelog lookup function needs to validate that the cached set
>> of revisions exposed to the view is still accurate. While there are
>> comments in repoview.py hinting at future optimizations to this
>> code, I think the ideal solution is to avoid having to validate a
>> cache altogether.
>>
>
> While I like the idea of having frozen repository, it introduce an
> additional level of complexity (somewhere already not simple) and will
> probably take some time to right and properly performing.
>
> Can we look at way to speed up the cache validation logic (or get a better
> approach for invalidating it, eg: nothing really change until we have a
> transaction).
>
> Speeding this would have a massive impact all across the board without
> changing much of the current architecture.
>
> I'll look at the implementation of the frozen repo more in details later.


Pierre-Yves just sent a refactor to repoview to remove a lot of the
overhead for .changelog lookup. His series seems to have the same
performance impact as my series. And his series doesn't introduce a
complicated new concept of "frozen repos" which would need to be utilized
all over the code base to become effective.

While I like the idea of a separate class for a read-only snapshot of the
state of a repository, I think that is an idea left for another day since
the main benefit (performance) is achieved through simpler means.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20151204/7b73bf09/attachment.html>