[PATCH 4 of 4] obsstore: cache size computation for fm1 node
Martin von Zweigbergk
martinvonz at google.com
Mon Dec 1 06:41:47 UTC 2014
Except for possibly documenting the runtimes including GC in the
description of 2/4, this series looks good to me.
On Sat Nov 29 2014 at 5:59:09 PM Pierre-Yves David <
pierre-yves.david at ens-lyon.org> wrote:
> # HG changeset patch
> # User Pierre-Yves David <pierre-yves.david at fb.com>
> # Date 1417073013 28800
> # Wed Nov 26 23:23:33 2014 -0800
> # Node ID 3e522f212318e467c5919a74de52c85f1a3ee0e7
> # Parent 0e7fa31502eeb5f3d347541e5c1caea4cb714d92
> obsstore: cache size computation for fm1 node
>
> We have two different types of node type (sha1 and sha256, only sha1 is
> used
> now) and therefor different sizes for them. We now compute the value once
> instead of redoing the computation every loop. This has no visible
> performance
> impact.
>
> diff --git a/mercurial/obsolete.py b/mercurial/obsolete.py
> --- a/mercurial/obsolete.py
> +++ b/mercurial/obsolete.py
> @@ -275,10 +275,12 @@ def _fm0decodemeta(data):
> # - remaining bytes: the metadata, each (key, value) pair after the other.
> _fm1version = 1
> _fm1fixed = '>IdhHBBB20s'
> _fm1nodesha1 = '20s'
> _fm1nodesha256 = '32s'
> +_fm1nodesha1size = _calcsize(_fm1nodesha1)
> +_fm1nodesha256size = _calcsize(_fm1nodesha256)
> _fm1fsize = _calcsize(_fm1fixed)
> _fm1parentnone = 3
> _fm1parentshift = 14
> _fm1parentmask = (_fm1parentnone << _fm1parentshift)
> _fm1metapair = 'BB'
> @@ -297,13 +299,14 @@ def _fm1readmarkers(data, off=0):
> if numpar == _fm1parentnone:
> numpar = None
> # build the date tuple (upgrade tz minutes to seconds)
> date = (seconds, tz * 60)
> _fm1node = _fm1nodesha1
> + fnodesize = _fm1nodesha1size
> if flags & usingsha256:
> _fm1node = _fm1nodesha256
> - fnodesize = _calcsize(_fm1node)
> + fnodesize = _fm1nodesha256size
> # read replacement
> sucs = ()
> if numsuc:
> s = (fnodesize * numsuc)
> cur = data[off:off + s]
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20141201/1ac733e6/attachment.html>
More information about the Mercurial-devel
mailing list