Pulkit Goyal <pulkit@yandex-team.ru> [Mon, 01 Apr 2019 13:56:47 +0300] rev 42121
branchcache: lazily validate nodes from the branchmap
On my personal hg-repository with 365 entries in .hg/cache/branch2, following
are the numbers for perfbranchmapload.
Before this patch:
! wall 0.000866 comb 0.000000 user 0.000000 sys 0.000000 (best of 2680)
! wall 0.001525 comb 0.000000 user 0.000000 sys 0.000000 (max of 2680)
! wall 0.001107 comb 0.001097 user 0.001086 sys 0.000011 (avg of 2680)
! wall 0.001104 comb 0.000000 user 0.000000 sys 0.000000 (median of 2680)
With this patch:
! wall 0.000530 comb 0.000000 user 0.000000 sys 0.000000 (best of 4240)
! wall 0.001078 comb 0.000000 user 0.000000 sys 0.000000 (max of 4240)
! wall 0.000696 comb 0.000693 user 0.000677 sys 0.000017 (avg of 4240)
! wall 0.000690 comb 0.000000 user 0.000000 sys 0.000000 (median of 4240)
On our internal repository with ~20k entries in branchcache, I see improvement
from 0.125 sec to 0.066 sec which is 47% speed up.
The above are the numbers of perfbranchmapload which shows how much time we
saved by not validating the nodes. But we need to validate some nodes. Following
are timings of some mercurial operations which have speed up because of this
lazy validation of nodes:
No-op `hg update` on our internal repository (Avg on 4 runs):
Before: 0.540 secs
After: 0.430 secs
Setting a branch name which already exists without --force (Avg of 4 runs):
Before: 0.510 secs
After: 0.250 secs
I ran the ASV performance suite and was unable to see any improvements except
there was improvement of perfdirstatewrite() on netbeans which I think was not
related.
I looked into the commit code, the command which I am trying to speedup, it
looks like it uses revbranchcache to update the branchcache.
Differential Revision: https://phab.mercurial-scm.org/D6208
Pulkit Goyal <pulkit@yandex-team.ru> [Tue, 19 Mar 2019 16:52:15 +0300] rev 42120
branchcache: add functions to validate changelog nodes
This patch adds functions to validate closed nodes, validate nodes for a certain
branch and for all the branches. These functions will be used in upcoming
patches.
Differential Revision: https://phab.mercurial-scm.org/D6207
Kyle Lippincott <spectral@google.com> [Mon, 15 Apr 2019 14:32:47 -0700] rev 42119
readline: provide styled prompt to readline (
issue6070)
Differential Revision: https://phab.mercurial-scm.org/D6168
Martin von Zweigbergk <martinvonz@google.com> [Tue, 02 Apr 2019 14:49:28 -0700] rev 42118
copies: move comment about implementation of mergecopies() to end
When you start reading about mergecopies(), you want to know what it
is, not that there are different implementations depending on config,
so this patch moves that comment to the end.
By the way, we don't seem to define what "copytracing" is. I'm just
leaving it that way because I don't know what it is myself. It seems
to be referred to only on mergecopies() (and not in pathcopies(), for
example), so maybe "copytracing" is supposed to be exactly what
mergecopies() does?
Differential Revision: https://phab.mercurial-scm.org/D6235
Martin von Zweigbergk <martinvonz@google.com> [Fri, 12 Apr 2019 23:26:08 -0700] rev 42117
remotefilelog: return expected type from copies overrides
copies._computeforwardmissing() and copies._computenonoverlap() return
sets, so the overrides should also do that.
Differential Revision: https://phab.mercurial-scm.org/D6234
Martin von Zweigbergk <martinvonz@google.com> [Sun, 24 Mar 2019 23:47:01 -0700] rev 42116
changelog: extract a _string_unescape() to mirror _string_escape()
We use our own _string_escape() to encode the "extras" field. Then we
use codecs.escape_decode() to escape it. But there's also a little
workaround for dealing with escaped text that looks like octal numbers
since the fix for
https://bz.mercurial-scm.org/show_bug.cgi?id=3156. This patch extracts
the call to codecs.escape_decode() along with the fix for octal
numbers and puts it in a _string_unescape(). It also updates the test
to check for the octal-number case from the aforementioned bug.
As you may have suspected, I want to be able to reuse this new
function later.
Differential Revision: https://phab.mercurial-scm.org/D6184
Martin von Zweigbergk <martinvonz@google.com> [Wed, 20 Mar 2019 11:42:02 -0700] rev 42115
copies: extract function for deciding whether to use changeset-centric algos
We'll eventually have a "experimental.copies.read-from=changeset-only"
option too and I don't want to spread the logic for determining if we
should use changeset-centric of filelog-centric algorithms.
Differential Revision: https://phab.mercurial-scm.org/D6163