f5a63a5506d2 regressed performance of baseset.__sub__ by introducing
a lazyset. This patch restores that lost performance by eagerly
evaluating baseset.__sub__ if the other set is a baseset.
revsetbenchmark.py results impacted by this change:
revset #6: roots(0::tip)
0) wall 2.923473 comb 2.920000 user 2.920000 sys 0.000000 (best of 4)
1) wall 0.077614 comb 0.080000 user 0.080000 sys 0.000000 (best of 100)
revset #23: roots((0:tip)::)
0) wall 2.875178 comb 2.880000 user 2.880000 sys 0.000000 (best of 4)
1) wall 0.154519 comb 0.150000 user 0.150000 sys 0.000000 (best of 61)
On the author's machine, this slowdown manifested during evaluation of
'roots(%ln::)' in phases.retractboundary after unbundling the Firefox
repository. Using `time hg unbundle firefox.hg` as a benchmark:
Before: 8:00
After: 4:28
Delta: -3:32
For reference, the subset and cs baseset instances impacted by this
change were of lengths 193634 and 193627, respectively.
Explicit test coverage of roots(%ln::), while similar to the existing
roots(0::tip) benchmark, has been added.
This patch changes the calling signature of memfilectx's __init__ to fall in
line with the other file contexts.
Calling code and tests have been updated accordingly.
On my Linux machine, paths seen by 2to3 include the build directory. We
switch from an exact to substring match to allow 2to3 to work in more
environments.
The ``editmerge`` script is shipped in contrib and opens an editor on
every conflicting file. It needs minimal configuration to inject the
config marker in the file before opening. Otherwise it behaves the
same as ``internal:local`` and bad things happen.
We add a -R/--repo option to run the benchmarks on another repository. This is
very useful as some repository are bigger/more interesting than the mercurial one.
Before this changeset, you had to stand in the root of the mercurial repo to run
the `revsetbenchmark.py` script. Otherwise, the perf extension would not be
found a `./contrib/perf.py` and the script would crash in panic.
We now figure out the contrib directory from the location of this script. This
makes it possible to run the script from other location that the mercurial repo
root (but you still need to be in the core mercurial repository)
This revset is used in evolve. The new revset lazyness should make it all faster
but in practice it is significantly slower.
Below is a timing for this entry on my Mercurial repo.
2.9.2) ! wall 0.034598 comb 0.040000 user 0.040000 sys 0.000000 (best of 100)
3.0+@) ! wall 0.062268 comb 0.060000 user 0.060000 sys 0.000000 (best of 100)
The ~20 have been taken arbitrary.
The check-code tool now expects the "desc" keyword to be followed by the
"websub" filter, with the following exceptions:
a) It has no filters at all, e.g. a changeset description in the raw style
templates or the repository description in the summary page.
b) It is followed by the "firstline" filter, e.g. the first line of the
changeset description is displayed as a summary or title.
This matters as `author(mpm)` have a lot of matches evenly split in the repo,
while `author(lmoscoviz)` have less match (and later). This changes the execution
path of the "or" operator a lot.
Calling a function is super expensive in python. We inline the trivial range
comparison to get back to more sensible performance on common revset operation.
Benchmark result below:
Revision mapping:
0) bced32a3fd6c 2.9.2 release
1) 2ab64f462d81 current @
2) This revision
revset #0: public()
0) wall 0.010890 comb 0.010000 user 0.010000 sys 0.000000 (best of 201)
1) wall 0.012109 comb 0.010000 user 0.010000 sys 0.000000 (best of 199)
2) wall 0.012211 comb 0.020000 user 0.020000 sys 0.000000 (best of 197)
revset #1: :10000 and public()
0) wall 0.007141 comb 0.010000 user 0.010000 sys 0.000000 (best of 361)
1) wall 0.014139 comb 0.010000 user 0.010000 sys 0.000000 (best of 186)
2) wall 0.008334 comb 0.010000 user 0.010000 sys 0.000000 (best of 308)
revset #2: draft()
0) wall 0.009610 comb 0.010000 user 0.010000 sys 0.000000 (best of 279)
1) wall 0.010942 comb 0.010000 user 0.010000 sys 0.000000 (best of 243)
2) wall 0.011036 comb 0.010000 user 0.010000 sys 0.000000 (best of 239)
revset #3: :10000 and draft()
0) wall 0.006852 comb 0.010000 user 0.010000 sys 0.000000 (best of 383)
1) wall 0.014641 comb 0.010000 user 0.010000 sys 0.000000 (best of 183)
2) wall 0.008314 comb 0.010000 user 0.010000 sys 0.000000 (best of 299)
We can see this changeset gains back the regression for `and` operation on
spanset. We are still a bit slowerfor the `public()` and `draft()`. Predicates
not touched by this changeset.
There can be good reasons to disable premerge no matter which merge tool is
used. Most tools will do just fine without premerge and handle the simple
merges more or less automatic and silent. We _could_ thus disable premerge for
most tools. But without premerge, the merge tool will be launched for each file
- that makes it a slow and expensive process to perform big simple merges. It
is thus better to consistently stick to the default premerge=True.
The mergetools.hgrc configuration for most tools implicitly use the default
premerge=True but Araxis and the Linux entry for Beyond Compare had
premerge=False. These lines has been removed.
These settings were introduced by de7cda55270e without further explanation of
why they should be good.
(We have seen some crashes on Windows with Araxis where a merge failed after a
lot of Araxis flashing. I haven't been able to reproduce it and do not know
exactly what happened. Enabling premerge avoids the problems.)
Before this patch, "contrib/check-code.py" can't detect "% inside _()"
correctly, when there are leading whitespaces before the format
string, like below:
_(
"format string %s" % v)
This patch adds regexp pattern "[ \t\n]*" before the pattern matching
against the format string.
"[\s\n]" can't be used in this purpose, because "\s" is automatically
replaced with "[ \t]" by "_preparepats()" and "\s" in "[]" causes
nested "[]" unexpectedly.
Previously revset._descendants would iterate over the entire subset (which is
often the entire repo) and test if each rev was in the descendants list. This is
really slow on large repos (3+ seconds).
Now we iterate over the descendants and test if they're in the subset.
This affects advancing and retracting the phase boundary (3.5 seconds down to
0.8 seconds, which is even faster than it was in 2.9). Also affects commands
that move the phase boundary (commit and rebase, presumably).
The new revsetbenchmark indicates an improvement from 0.2 to 0.12 seconds. So
future revset changes should be able to notice regressions.
I removed a bad test. It was recently added and tested '1:: and reverse(all())',
which has an amibiguous output direction. Previously it printed in reverse order,
because we iterated over the subset (the reverse part). Now it prints in normal
order because we iterate over the 1:: . Since the revset itself doesn't imply an
order, I removed the test.
Before this patch, "contrib/check-code.py" can't detect these
problems, because the regexp pattern to detect "% inside _()" doesn't
suppose the case that format string consists of multiple string
components concatenated implicitly or explicitly,
This patch does below for that regexp pattern to detect "% inside _()"
problems in such case.
- put "+" into separator part ("[ \t\n]") for explicit concatenation
("...." + "...." style)
- enclose "component and separator" part by "(?:....)+" for
concatenation itself ("...." "...." or "...." + "....")
Before this patch, "contrib/check-code.py" can't detect these
problems, because the regexp pattern to detect "% inside _()" doesn't
suppose the case that the format string and "%" aren't placed in the
same line.
This patch replaces "\s" in that regexp pattern with "[ \t\n]" to
detect "% inside _()" problems in such case.
"[\s\n]" can't be used in this purpose, because "\s" is automatically
replaced with "[ \t]" by "_preparepats()" and "\s" in "[]" causes
nested "[]" unexpectedly.
The script is now in python. That translation is very raw, more improvement to
comes:
The "current code" and "base" entry have been dropped. This is trivial to get
same result using a tagged revision or "." in the list of benchmarked revision.
With the new lazy revset implementation, we need to actually read all elements
to trigger all the computations. Otherwise a no-op if of course much faster than
the full work.
Newly added "hgperf" command repeats "dispatch.runcommand()" for
specified Mercurial command and measure performance of it in the same
manner of "contrib/perf.py" extension.
Users (mainly developers) can examine performance of the target
command easily, without adding new entry for it to "contrib/perf.py"
extension.
