Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 09 Jun 2015 23:45:34 -0700] rev 25543
revsetbenchmarks: support combining variants with "+"
We need more advanced variants in some cases. For example, "The last
rev of the sorted version".
We introduce a syntax for this: `reverse+last` means `last(reverse(REVSET))`.
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 09 Jun 2015 21:10:44 -0700] rev 25542
revsetbenchmarks: use many more variants by default
So far the variants feature was introduced, but not used by
default. We now use a set of basic variants by default.
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 09 Jun 2015 21:20:54 -0700] rev 25541
revsetbenchmarks: display even more compact timing result
We now use an 8 char display for timing (from 10), we add some logic to drop
precision if the number grows too large (as we do not care about sub-0 digit
in this case). This allow to pack more variants in a single screen.
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 27 Oct 2014 11:59:39 +0100] rev 25540
revsetbenchmarks: allow running multiple variants per revset
The current benchmarks were only testing the whole iteration. This is suboptimal
because some changes are meaningful for things like first result, minimum or
sorting.
We introduce a "variants" feature that let you systematically add some variants
to all revsets tested.
A typical variants value would be 'plain,min,last,sort'. When testing 'all()' it
will also provide testing for:
- all()
- min(all())
- last(all())
- sort(sort)
and output:
plain min last sort
0) 0.034568 0.037857 0.000074 0.034238
1) 0.011358 32% 0.020181 53% 0.000080 108% 0.011405 33%
Using revsets (who hit the API) instead of the internal API add some overhead,
but the overhead should be the same everywhere so it still allow comparison.
This is is more simple to implement and allows comparison with older versions
who do not have the same API.
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 09 Jun 2015 21:30:04 -0700] rev 25539
revsetbenchmarks: display relative change when meaningful
If the time difference is more than 5% from the previous run, we'll display
relative information. This makes it much simpler to spot performance changes in
a sea of benchmarks.
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 09 Jun 2015 18:53:04 -0700] rev 25538
revsetbenchmarks: improve revision printing
We now print the revision number and short hash inline. As a result we drop the
crappy list printing.
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 09 Jun 2015 18:40:06 -0700] rev 25537
revsetbenchmarks: hide most timing under a --verbose flag
We mostly only care about total time. Dropping this output give us some room to
display more useful information (like percentage different) in future
changesets.
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 09 Jun 2015 18:32:47 -0700] rev 25536
revsetbenchmarks: drop outdated comment
We are no longer testing against system mercurial for quite some time.
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 09 Jun 2015 18:39:55 -0700] rev 25535
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.
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 09 Jun 2015 17:15:48 -0700] rev 25534
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.
Augie Fackler <augie@google.com> [Fri, 12 Jun 2015 16:42:07 -0400] rev 25533
revsetbenchmarks: clarify comment based on irc discussion
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 11 Jun 2015 10:55:02 -0700] rev 25532
revsetbenchmarks: ensure all indexes have the same width
This avoids an alignment glitch.
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 09 Jun 2015 16:57:18 -0700] rev 25531
revsetbenchmarks: factor out result output into a function
This will make update of the output easier.
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 09 Jun 2015 16:48:29 -0700] rev 25530
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/).
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 09 Jun 2015 15:58:48 -0700] rev 25529
revsetbenchmarks: improve error output in case of failure
This helps with diagnostics.
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 09 Jun 2015 15:49:14 -0700] rev 25528
revsetbenchmarks: extract call to mercurial into a function
This is a gratuitous change to make the code easier to look at.
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 10 Jun 2015 19:26:16 -0700] rev 25527
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
Anton Shestakov <av6@dwimlabs.net> [Fri, 12 Jun 2015 18:34:10 +0800] rev 25526
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'.
Anton Shestakov <av6@dwimlabs.net> [Fri, 12 Jun 2015 16:09:59 +0800] rev 25525
hgweb: don't point graph 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.
When monoblue style was added in 91b0ada2d94b, however, all graph links had
tried to point at some hash, and on such pages as described above it didn't
make sense. On error pages '{node|short}' is empty string anyway.
Of course, it worked, but seeing such 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 wasn't consistent with other template styles, other
pages in monoblue and even other links on the same page.
Let's just link to '/graph', which is equal to '/graph/tip'.
Anton Shestakov <av6@dwimlabs.net> [Fri, 12 Jun 2015 15:29:12 +0800] rev 25524
hgweb: put help link in paper/search.tmpl separately for consistency
Just a cosmetic markup change, no .css changes required.
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 11 Jun 2015 00:26:06 -0700] rev 25523
help: use 'color' as an example (instead of 'progress')
Progress is now deprecated, using it as an example is suboptimal.
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 08 Jun 2015 01:01:21 -0700] rev 25522
progress: deprecate the progress extension
Activating it is a absolute no-op now.
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 08 Jun 2015 01:00:47 -0700] rev 25521
progress: empty the extension of any logic
The default value match the one enforce by the extension, we can remove that
logic.
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 10 Jun 2015 11:56:55 -0700] rev 25520
progress: move config help into core config help
This is core feature now.
Pierre-Yves David <pierre-yves.david@fb.com> [Sun, 07 Jun 2015 17:51:27 -0700] rev 25519
progress: display progress bars by default with core Mercurial
As discussed multiple time during sprint, we should activate progress by
default. Having progress bar significantly improve the user experience.
Pierre-Yves David <pierre-yves.david@fb.com> [Sun, 07 Jun 2015 15:57:54 -0700] rev 25518
bundle2: provide number of changesets information to 'addchangegroup'
We can now link the two efforts and provided more useful information when
pulling changesets.
Pierre-Yves David <pierre-yves.david@fb.com> [Sun, 07 Jun 2015 15:57:40 -0700] rev 25517
addchangegroup: accept an expected total number of changesets as argument
Caller can optionally informs how much changesets are expected to be added. This
will be used for a more useful progress bar output.
Pierre-Yves David <pierre-yves.david@fb.com> [Sun, 07 Jun 2015 15:52:57 -0700] rev 25516
getbundle: add data about the number of changesets bundled
We use an advisory parameters to carry the number of changesets bundled. This
will be used for progress output.