Thu, 01 May 2014 09:42:23 -0500 tests: add repository check for pyflakes test stable
Matt Mackall <mpm@selenic.com> [Thu, 01 May 2014 09:42:23 -0500] rev 21208
tests: add repository check for pyflakes test If this test was run from a tarball with no Mercurial repository, it would fail because 'hg manifest' didn't work.
Sat, 26 Apr 2014 00:38:02 -0700 spanset: directly use __contains__ instead of a lambda stable
Pierre-Yves David <pierre-yves.david@fb.com> [Sat, 26 Apr 2014 00:38:02 -0700] rev 21207
spanset: directly use __contains__ instead of a lambda Spanset are massively used in revset. First because the initial subset itself is a repo wide spanset. We speed up the __and__ operation by getting rid of a gratuitous lambda call. A more long terms solution would be to: 1. speed up operation between spansets, 2. have a special smartset for `all` revisions. In the mean time, this is a very simple fix that buyback some of the performance regression. Below is performance benchmark for trival `and` operation between two spansets. (Run on an unspecified fairly large repository.) revset tip:0 2.9.2) wall 0.282543 comb 0.280000 user 0.260000 sys 0.020000 (best of 35) before) wall 0.819181 comb 0.820000 user 0.820000 sys 0.000000 (best of 12) after) wall 0.645358 comb 0.650000 user 0.650000 sys 0.000000 (best of 16) Proof of concept implementation of an `all` smartset brings this to 0.10 but it's too invasive for stable.
Wed, 30 Apr 2014 15:36:38 -0700 transaction: fix file descriptor leak for journal.backupfiles stable
Durham Goode <durham@fb.com> [Wed, 30 Apr 2014 15:36:38 -0700] rev 21206
transaction: fix file descriptor leak for journal.backupfiles The journal.backupfiles descriptor wasn't being closed. This resulted in hgsubversion test runs having a bagillion descriptors open, which crashed on platforms with low open file limits (like OSX).
Fri, 25 Apr 2014 18:00:07 -0700 revset: also inline spanset._contained in __len__ stable
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 25 Apr 2014 18:00:07 -0700] rev 21205
revset: also inline spanset._contained in __len__ For consistency with what happen in `__contains__`, we inline the range test into `__len__` too.
Mon, 28 Apr 2014 15:15:36 -0700 revset: inline spanset containment check (fix perf regression) stable
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 28 Apr 2014 15:15:36 -0700] rev 21204
revset: inline spanset containment check (fix perf regression) 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) 3f83fc5cfe71 2.9.2 release 1) bcfd44abad93 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.
Wed, 30 Apr 2014 14:19:01 -0500 ancestor: silence multiple ancestor warning outside of merge (issue4234) stable
Matt Mackall <mpm@selenic.com> [Wed, 30 Apr 2014 14:19:01 -0500] rev 21203
ancestor: silence multiple ancestor warning outside of merge (issue4234) The current situation is a bit of a layering violation as merge-specific knowledge is pushed down to lower layers and leaks merge assumptions into other code paths. Here, we simply silence the warning with a hack. Both the warning and the hack will probably go away in the near future when bid merge is made the default.
(0) -10000 -3000 -1000 -300 -100 -30 -10 -6 +6 +10 +30 +100 +300 +1000 +3000 +10000 +30000 tip