Gregory Szorc <gregory.szorc@gmail.com> [Sat, 06 May 2017 12:12:53 -0700] rev 32229
revlog: rename _chunkraw to _getsegmentforrevs()
This completes our rename of internal revlog methods to
distinguish between low-level raw revlog data "segments" and
higher-level, per-revision "chunks."
perf.py has been updated to consult both names so it will work
against older Mercurial versions.
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 06 May 2017 12:02:31 -0700] rev 32228
perf: store reference to revlog._chunkraw in a local variable
To prepare for renaming revlog._chunkraw, we stuff a reference to this
metho in a local variable. This does 2 things. First, it moves the
attribute lookup outside of a loop, which more accurately measures
the time of the code being invoked. Second, it allows us to alias
to different methods depending on their presence (perf.py needs to
support running against old Mercurial versions).
Removing an attribute lookup from a tigh loop appears to shift the
numbers slightly with mozilla-central:
$ hg perfrevlogchunks -c
! read
! wall 0.354789 comb 0.340000 user 0.330000 sys 0.010000 (best of 28)
! wall 0.335932 comb 0.330000 user 0.290000 sys 0.040000 (best of 30)
! read w/ reused fd
! wall 0.342326 comb 0.340000 user 0.320000 sys 0.020000 (best of 29)
! wall 0.332857 comb 0.340000 user 0.290000 sys 0.050000 (best of 30)
! read batch
! wall 0.023623 comb 0.020000 user 0.000000 sys 0.020000 (best of 124)
! wall 0.023666 comb 0.020000 user 0.000000 sys 0.020000 (best of 125)
! read batch w/ reused fd
! wall 0.023828 comb 0.020000 user 0.000000 sys 0.020000 (best of 124)
! wall 0.023556 comb 0.020000 user 0.000000 sys 0.020000 (best of 126)
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 06 May 2017 12:02:12 -0700] rev 32227
revlog: rename internal functions containing "chunk" to use "segment"
Currently, "chunk" is overloaded in revlog terminology to mean
multiple things. One of them refers to a segment of raw data from
the revlog. This commit renames various methods only used within
revlog.py to have "segment" in their name instead of "chunk."
While I was here, I also made the names more descriptive. e.g.
"_loadchunk()" becomes "_readsegment()" because it actually does
I/O.
Jun Wu <quark@fb.com> [Sat, 06 May 2017 16:36:24 -0700] rev 32226
fsmonitor: do not nuke dirstate filecache
In the future, chg may prefill repo's dirstate filecache so it's valuable
and should be kept. Previously we drop both filecache and property cache for
dirstate during fsmonitor reposetup, this patch changes it to only drop
property cache but keep the filecache.
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 06 May 2017 11:01:02 -0700] rev 32225
perf: move gettimer() call
This is more consistent with other perf* functions.
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 06 May 2017 10:59:38 -0700] rev 32224
perf: don't clobber startrev variable
Previously, the "startrev" argument would be ignored due to
"startrev = 0" in the benchmark function. This meant that
`hg perfrevlog` always started at revision 0.
Rename the local variable to "beginrev" so the variable does the
right thing.
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 05 May 2017 17:31:15 +0200] rev 32223
bundle: add optional 'tagsfnodecache' data to on disk bundle (
issue5543)
This should help performance when unbundling.
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 05 May 2017 17:28:52 +0200] rev 32222
bundle2: move tagsfnodecache generation in a generic function
This will help us reusing the logic for `hg bundle`.
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 05 May 2017 17:09:47 +0200] rev 32221
bundle: introduce an higher level function to write bundle on disk
The current function ('writebundle') is focussing on getting an existing
changegroup to disk. It is no easy ways to includes more part in the generated
bundle2. So we introduce a slightly higher level function that is fed the
'outgoing' object (that defines the bundled spec) and the bundlespec parameters
(to control the changegroup generation and inclusion of other parts).
This is creating the third logic dedicated to create a consistent bundle2 (the
other 2 are the push code and the getbundle code). We should probably reconcile
them at some points but they all takes different types of input. So we need to
introduce an intermediate "object" that each different input could be converted
to. Such unified "bundle2 specification" could be fed to some unified code.
We start by having the `hg bundle` related code on its own to helps defines its
specific needs first. Once the common and specific parts of each logic will be
known we can start unification.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 04 May 2017 21:47:03 +0200] rev 32220
bundle: handle compression earlier
We can also handle that part before starting any generation.