In multiple places in the code, we use `someset[0]` or `someset[-1]`. This
works only because the `someset` is usually a baseset. For the same reason we
introduce a `first` and `last` methods to be implemented for all smartset
classes.
A `baseset` has multiple cached results and will get even more in the future.
Making it an object "populated once" like the other smartsets makes it both safer
and simpler. The append method will be removed at some point.
A `baseset` has multiple cached results and will get even more in the future.
Making it an object "populated once" like the other smartsets makes it both safer
and simpler. The append method will be removed at some point.
A `baseset` has multiple cached results and will get even more in the future.
Making it an object "populated once" like the other smartsets makes it both safer
and simpler. The append method will be removed at some point.
A `baseset` has multiple cached results and will get even more in the future.
Making it an object "populated once" like the other smartsets makes it both safer
and simpler. The append method will be removed at some point.
Sorting is super-cheap with the new smartset class, so we can use it to enforce
the order. Otherwise all smartset classes would have to allow direct indexing.
The expected iteration order may be different than the fast iteration order (eg:
ancestors(42) is expected to be iterated upward but is fast/lazy to compute
downward.
So we explicitly track the iteration order and enforce it if the manual
iteration is requested.
Default expected iteration order of a generator set is ascending because I'm
not aware of any descending revset that need a generatorset. The first to find
such descending revset will have the pleasure to make this configurable.
The utility of this cache is debatable (no visible benchmark impact) and using
generatorset for such purpose makes the code complicated.
We drop it for now. Someone can reintroduce a smart version of it in the future
if it is detected to be relevant.
When all revisions are known, we shortcut most of the class logic to use list
iteration instead. The cost of the sort is expected to be non-significant. The
list creation and sorting could be done lazily in the future. We have to copy
the list to not break existing iterator created before we finished consuming the
generator.
Omit the check of bool(p1) since it's always true in practice: it will
either be nullid or some valid manifest sha, and we know nullid won't
ever be in the cache so we can simplify understanding of this code.
I verified that changed was never false (it was always a 2-tuple) by
adding
@@ -220,6 +225,8 @@ class manifest(revlog.revlog):
def add(self, map, transaction, link, p1=None, p2=None,
changed=None):
+ if not changed:
+ assert False, 'changed was %r' % changed
# if we're using the cache, make sure it is valid and
# parented by the same node we're diffing against
if not (changed and p1 and (p1 in self._mancache)):
and observing that the test suite still passed. Making all the
arguments required should help future readers understand what's going
on here.
Since ce44c3c7c2be, we have a diff.nobinary option. This is handy, but
the only way I found out about it was by looking at the release notes
for 3.1, which is not something I normally do.
Since 266cfa7de44d, --template option is ignored if --style is specified,
which is wrong according to the doc of show_changeset():
Display format will be the first non-empty hit of:
1. option 'template'
2. option 'style'
...
Make hgweb.refresh() also look at phaseroots file (in addition to 00changelog.i
file) and reload the repo when os.stat returns different mtime or size than
cached, signifying the file was modified.
This way if user changes phase of a changeset (secret <-> draft), there's no
need to restart hg serve to see the change.
This will make it possible for subclasses to have different hashing
schemes when appropriate. I anticipate using this in manifests.
Note that there's still one client of mercurial.revlog.hash() outside
of revlog: mercurial.context.memctx uses it to construct the file
entries in an in-memory manifest. I don't think this will be a problem
in the immediate future, so I've left it as-is.
d735f8a82023 is nice for test output, but it also affects command-server
channel. Command-server client shouldn't receive echo-back message, which
makes it harder to parse the output.
This is a small win on OS X. hg perfdirstatefoldmap:
before: wall 0.399708 comb 0.410000 user 0.390000 sys 0.020000 (best of 25)
after: wall 0.386331 comb 0.390000 user 0.370000 sys 0.020000 (best of 25)
Constructing the foldmap is much faster on OS X now. For a large real-world
repo, hg perfdirstatefoldmap:
before: wall 0.805278 comb 0.800000 user 0.790000 sys 0.010000 (best of 13)
after: wall 0.399708 comb 0.410000 user 0.390000 sys 0.020000 (best of 25)
This is a nice boost to 'hg status', especially with the third-party hgwatchman
extension enabled (which eliminates stat calls). For the above repo, 'hg
status' goes from 1.17 seconds to 0.74.
This benefits, among other things, the case collision auditor.
On a Linux system with a large real-world repo where all filenames are ASCII,
hg perfcca:
before: wall 0.260157 comb 0.270000 user 0.230000 sys 0.040000 (best of 38)
after: wall 0.164616 comb 0.160000 user 0.160000 sys 0.000000 (best of 54)
We need a way to efficiently lowercase ASCII strings. For example, 'hg status'
needs to build up the fold map -- a map from a canonical case (for OS X,
lowercase) to the actual case of each file and directory in the dirstate.
The current way we do that is to try decoding to ASCII and then calling
lower() on the string, labeled 'orig' below:
str.decode('ascii')
return str.lower()
This is pretty inefficient, and it turns out we can do much better.
I also tested out a condition-based approach, labeled 'cond' below:
(c >= 'A' && c <= 'Z') ? (c + ('a' - 'A')) : c
'cond' turned out to be slower in all cases. A 256-byte lookup table with
invalid values for everything past 127 performed similarly, but this was less
verbose.
On OS X 10.9 with LLVM version 6.0 (clang-600.0.51), the asciilower function
was run against two corpuses.
Corpus 1 (list of files from real-world repo, > 100k files):
orig: wall 0.428567 comb 0.430000 user 0.430000 sys 0.000000 (best of 24)
cond: wall 0.077204 comb 0.070000 user 0.070000 sys 0.000000 (best of 100)
lookup: wall 0.060714 comb 0.060000 user 0.060000 sys 0.000000 (best of 100)
Corpus 2 (mozilla-central, 113k files):
orig: wall 0.238406 comb 0.240000 user 0.240000 sys 0.000000 (best of 42)
cond: wall 0.040779 comb 0.040000 user 0.040000 sys 0.000000 (best of 100)
lookup: wall 0.037623 comb 0.040000 user 0.040000 sys 0.000000 (best of 100)
On a Linux server-class machine with GCC 4.4.6 20120305 (Red Hat 4.4.6-4):
Corpus 1 (real-world repo, > 100k files):
orig: wall 0.260899 comb 0.260000 user 0.260000 sys 0.000000 (best of 38)
cond: wall 0.054818 comb 0.060000 user 0.060000 sys 0.000000 (best of 100)
lookup: wall 0.048489 comb 0.050000 user 0.050000 sys 0.000000 (best of 100)
Corpus 2 (mozilla-central, 113k files):
orig: wall 0.153082 comb 0.150000 user 0.150000 sys 0.000000 (best of 65)
cond: wall 0.031007 comb 0.040000 user 0.040000 sys 0.000000 (best of 100)
lookup: wall 0.028793 comb 0.030000 user 0.030000 sys 0.000000 (best of 100)
SSE instructions might help even more, but I didn't experiment with those.
The 'always' class calls its parent constructor with an empty list of
patterns, which will result in a matcher that always matches. The
parent constructor will set self._always to True in such cases, so
there is no need to set it again.
This clarifies that "no bookmarks set" is displayed in addition to the list
of bookmarks. In JSON output, for example, [] should be written if empty,
and "no bookmarks set" message should be skipped.
We have been running hiddencache verification since 3.1.1 and so
far not received a bug report concerning it. Therefore we remove
the verification code and make the hiddencache authoritive. That
way we get the intended speedup.
The color docstring was getting long. This splits it up into
bite-sized sections and rearranges the order of the paragraphs a
little to match these sections.
