revsetbenchmarks: fix argument parsing
The file doc was saying something, the code was doing something else, the
argument validation was doing a third thing.
Doc and behavior now comply with the argument defined in the code.
revsetbenchmarks: use a more compact output format with a header
We change the output from:
revset #0: draft()
0) wall 0.011989 comb 0.010000 user 0.000000 sys 0.010000 (best of 177)
1) wall 0.012226 comb 0.010000 user 0.000000 sys 0.010000 (best of 193)
2) wall 0.011838 comb 0.020000 user 0.000000 sys 0.020000 (best of 208)
to:
revset #0: draft()
wall comb user sys count
0) 0.012028 0.010000 0.000000 0.010000 170
1) 0.012218 0.010000 0.000000 0.010000 157
2) 0.012622 0.010000 0.000000 0.010000 189
This opens the road to more useful output.
revsetbenchmarks: ensure all indexes have the same width
This avoids an alignment glitch.
revsetbenchmarks: factor out result output into a function
This will make update of the output easier.
revsetbenchmarks: parse perfrevset output into actual number
We cannot just ask perfrevset to provide debug output because we usually want
to compare output from old version of Mercurial that do not support it. So, we
are using a regular expression.
(/we now have \d problems/).
revsetbenchmarks: improve error output in case of failure
This helps with diagnostics.
revsetbenchmarks: extract call to mercurial into a function
This is a gratuitous change to make the code easier to look at.
phases: really fix native phase computation
For some reason (probably rebase issue, leprechaun or badly resolved .rej)
1635579f9baf contains only half of the emailed patches and do not fix the bug.
This patch adds the other half and enable the sweet native computation for real.
As expected this provide massive speedup along the board.
revset #0: not public()
plain first
0) 0.011960 0.010523
1) 0.000465 3% 0.000492 4%
revset #1: (tip~1000::) - public()
plain first
0) 0.025700 0.025169
1) 0.002864 11% 0.001899 7%
revset #2: not public() and branch("default")
plain first
0) 0.022842 0.020863
1) 0.011418 49% 0.010948 52%
However, it has a less impact (even bad) on first result time in simple
situation. This comes from the overhead of building the set and filtering it.
This is especially true on my Mercurial repository (used here) where about 1/3
of the changesets are non public and hidden. This could be mitigated by a
caching of the set and a better usage of smartset in '_notpublic'. (But this
won't happen in this patch because the win is massive everywhere else).
revset #0: not public()
last
0) 0.000081
1) 0.000493 x6.1 <-- bad impact
revset #1: (tip~1000::) - public()
last
0) 0.013966
1) 0.002737 19%
revset #2: not public() and branch("default")
last
0) 0.011021
1) 0.011038
The effect mostly disappear when the number of non-public changesets is small
and/or the repo get bigger. Result for Mozilla central:
Mozilla
revset #0: not public()
plain first last
0) 0.092787 0.084094 0.000080
1) 0.000054 0% 0.000083 0% 0.000083
revset #1: (tip~1000::) - public()
plain first last
0) 0.215607 0.183996 0.124962
1) 0.031620 14% 0.006616 3% 0.031168 24%
revset #2: not public() and branch("default")
plain first last
0) 0.092626 0.082687 0.000162
1) 0.000139 0% 0.000165 0% 0.000167
hgweb: don't point file links at tip hash where it doesn't make sense
Some pages, e.g. bookmarks, help and summary don't have a meaningful revision
context: they always either show information about tip or about the whole repo
(and not about any specific changeset). And error pages can just show hgweb
error messages, not related to any repo or changeset.
Having a hash in the links worked (even when '{node|short}' resolved to an
empty string on error pages), but seeing pages without revision context provide
links with hashes is a bit confusing (unless you keep current tip hash in your
head at all times) and not consistent with other template styles and other
links on the same page: they don't have a hash.
Let's just link to '/file', which is equal to '/file/tip'.