[PATCH 3 of 3] revlog: remove cache validation

Gregory Szorc gregory.szorc at gmail.com
Sun Nov 22 22:43:08 CST 2015


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

>
>
> On 11/22/2015 07:34 PM, Gregory Szorc wrote:
>
>> # HG changeset patch
>> # User Gregory Szorc <gregory.szorc at gmail.com>
>> # Date 1448243855 28800
>> #      Sun Nov 22 17:57:35 2015 -0800
>> # Node ID 3818d1ea14c24c73f23925dcee21d0f71fb7a8b5
>> # Parent  9b10f53e1f1a8ab3850577610498dff590ee8357
>> revlog: remove cache validation
>>
>> Previously, we likely called _chunkraw() multiple times in order to
>> ensure it didn't change out from under us. I'm pretty certain this code
>> had its origins in the days where we attempted to have thread safety of
>> localrepository and thus revlog instances.
>>
>> revlog instances are already not thread safe for writing. And, as of
>> Mercurial 3.6, hgweb uses a separate localrepository instance per
>> request, so there is no thread contention. We more or less decided
>> that attempting to make classes like revlog thread safe is a lost
>> cause.
>>
>> So, this patch removes thread safety from _chunks. As a result, we make
>> one less call into _chunkraw() when the initial read isn't serviced
>> by the cache. This translates to savings of 4 function calls overall
>> and possibly prevents the creation of an additional buffer view into the
>> cache. I doubt this translates into any real world performance wins
>> because decompression will almost certainly dwarf time spent in
>> _chunks().
>>
>
>
> The series looks good, but why are we doing all this if this the win is
> unlikely to be relevant?
>

I have a few more patches queued up. Starting with a fix for issue4961. I'm
trying to make revlog reading significantly faster by employing cache
magic. I'm holding off on the 4961 fix because I want to be sure my
followup work doesn't necessitate additional refactoring.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20151122/03c9ab9e/attachment.html>


More information about the Mercurial-devel mailing list