Skip to content
Snippets Groups Projects
  1. Jul 08, 2018
  2. Jun 21, 2018
  3. Jun 26, 2018
    • Sean Farley's avatar
      revset: add optimization for heads(commonancestors()) · 52f19a84
      Sean Farley authored
      Previously, the only way to get these commits were (tested on
      mozilla-central):
      
      hg perfrevset 'heads(::a7cf55 and ::d8b15)'
      ! wall 4.988366 comb 4.960000 user 4.780000 sys 0.180000 (best of 3)
      
      After this patch:
      
      (python)
      hg perfrevset 'heads(commonancestors(a7cf55 + d8b15))'
      ! wall 0.002155 comb 0.000000 user 0.000000 sys 0.000000 (best of 1107)
      
      (C)
      hg perfrevset 'heads(commonancestors(a7cf55 + d8b15))'
      ! wall 0.000568 comb 0.000000 user 0.000000 sys 0.000000 (best of 4646)
      52f19a84
  4. Jun 19, 2018
    • Sean Farley's avatar
      revsets: add commonancestors revset · 54609263
      Sean Farley authored
      This is a method to reproduce "::x and ::y" such that a set can be sent
      in. For instance, it'd be convenient to have "::heads()" work like this
      but that already means "::x + ::y + ..." for each element in the
      "heads()" set.
      
      Therefore, we add the "commonancestors" method to mean "::x and ::y ..."
      for each head in the given set.
      54609263
  5. Jul 09, 2018
  6. Jul 10, 2018
  7. Jun 05, 2018
  8. May 28, 2018
  9. May 24, 2018
  10. Apr 28, 2018
  11. Mar 15, 2018
  12. Jun 10, 2018
    • Yuya Nishihara's avatar
      fileset: pass in badfn to inner matchers · 5cbcbe51
      Yuya Nishihara authored
      Just for sanity. No idea if this will make a difference, but it should
      propagate the badfn because the matcher created by mctx.matcher() will be
      returned by fileset.match() in future patches.
      5cbcbe51
  13. Jun 09, 2018
    • Yuya Nishihara's avatar
      fileset: restrict getfileset() to not return a computed set (API) · 760cc5dc
      Yuya Nishihara authored
      And rename the functions accordingly. fileset.match() will be changed to
      not compute the initial subset.
      
      test-glog*.t get back to the state before 9f9ffe5f687c "match: compose
      'set:' pattern as matcher."
      760cc5dc
    • Yuya Nishihara's avatar
      match: add prefixdirmatcher to adapt subrepo matcher back · 0ba4cf3f
      Yuya Nishihara authored
      This serves as an inverse function to the subdirmatcher, and will be used
      to wrap a fileset matcher of subrepositories. One of the root/prefix paths
      could be deduced from the matcher attributes to be wrapped, but we don't
      since the callers of this class know the root/prefix paths and can simply
      pass them in.
      0ba4cf3f
    • Yuya Nishihara's avatar
      fileset: make debugfileset filter repository files · 3d8ef605
      Yuya Nishihara authored
      This prepares for the structural change of the fileset. A computed fileset
      will no longer be a set of files, but a boolean function (i.e. matcher) to
      test if an input file matches the given fileset expression.
      
      --all-files option is added because some examples in the test need to scan
      files across revisions.
      3d8ef605
  14. Jul 08, 2018
  15. Jun 21, 2018
    • Paul Morelle's avatar
      aggressivemergedeltas: enabled the option by default · 44f5acfb
      Paul Morelle authored
      The option has been around for a while (August 2015) but was never turned on by
      default. In-depth testing shows large wins for having that on with no
      significant drawbacks.
      
      When enabled, revlog consider delta against both p1 and p2 at the same time when
      storing a revision. Selecting a delta against "p2" can produce better deltas and
      chain. This raise large benefit for all repositories, especially if they have a
      lot of merges.
      
      Comparison of `.hg/store/` size:
      
          mercurial (6.74% merges):
              before:    54,225,348 bytes
              after:     47,279,959 bytes -13%
          pypy (8.30% merges):
              before:   459,041,759 bytes
              after:    346,090,067 bytes -25%
          netbeans (34.21% merges):
              before: 2,468,041,333 bytes
              after:  1,364,077,645 bytes -45%
          mozilla-central (4.84% merges):
              before: 2,731,799,546 bytes
              after:  2,157,718,019 bytes -21%
      
      Comparison of `00manifest.d` size:
      
          mercurial (6.74% merges):
              before:    11,682,516 bytes
              after:      6,143,044 bytes -47%
          pypy (8.30% merges):
              before:   156,447,163 bytes
              after:     52,941,780 bytes -66%
          netbeans (34.21% merges):
              before: 1,250,363,851 bytes
              after:    130,088,982 bytes -90%
          mozilla-central (4.84% merges):
              before:   468,202,733 bytes
              after:    215,096,339 bytes -54%
      
      In addition, the better deltas help with the performance of multiple core
      operations. However, better chains mean longer chains, which can affect
      performance negatively (mostly manifest revision retrieval time). Chains length
      is a deeper problem that also affects linear repository too. Overall we think
      the benefits of using p2 as a diff target are bigger than the downsizes. In
      addition, we are also working on ways to improve the performance impact of chain
      length, so theses downsizes get fixed in the future.
      
      Below are interesting items from the full benchmark run:
      
          bundling 100 revisions from pypy:
              before: 670ms
              after:  480ms -28%
          bundle 10000 revisions from pypy:
              before: 1.38s
              after:  1.10s -54%
          bundle 10000 revisions from pypy:
              before: 16.1s
              after:  7.81s -52%
          bundle 10000 revisions from netbeans:
              before: 19.3s
              after:  15.5s -19%
      
          unbundle 1000 revisions to pypy:
              before: 641ms
              after:  315ms - 51%
      
          clone mercurial (http):
              before: 26.0s
              after:  22.6s -23%
      
          pulling 1000 revisions from pypy (shh):
              before: 2.07s
              after:  1.36s -44%
      
          pushing 1000 revision through http (pypy repository)
              before: 2.18s
              after:  1.35s -48%
      
          diff time in mozilla-central:
              before: 1.420s
              after:  0.983s -31%
      
          status time in mozilla-central:
              before: 1.260s
              after:  0.828s -34%
      
      Impact in other cases seems minimal (within a couple of percent in worse cases)
      and can be seen in both direction:
      
      Timing for a simple `hg commit`:
      
          mozilla-central:
              before: 3.37s
              after:  3.22s -4%
          pypy:
              before:  194ms
              after:   197ms +2%
      
      Timing for status (from tip to parent of tip):
          mercurial:
              before: 52.4ms
              after:  52.4ms (same)
          pypy:
              before: 55.2
              after:  56.9 +3%
      
      Timing for `hg update`
      
          mozilla-central, across 10 revisions:
              before: 4.82s
              after:  4.59s -5%
          mozilla-central, across 10000 revisions:
              before: 49.1s
              after:  49.9s +2%
          pypy, across 10 revisions:
              before: 213ms
              after:  216ms +1%
          pypy, across 10000 revisions:
              before: 5.31ms
              after:  5.24ms -1%
      
      The negative consequences are related to manifest fetch time:
      (timing for the tip revision tested by the benchmark)
      
          pypy-2018:
              before: 2.60ms
              after:  3.88ms +50%
          mozilla-central-2018:
              before: 565ms
              after:  652ms +15% (~+100ms)
          netbeans-2018:
              before: 101ms
              after:  250ms +48% (~+150ms)
      
      This shows up as a fixed overhead on some command we benchmarked:
      
          no-op push of mozilla-central:
              before:  945ms
              after:  1040ms +10% (~+100ms)
          pushing 10 changeset in netbeabs over ssh:
              before:  557ms
              after:   712ms +28% (+155ms)
          pushing 100 changeset in netbeabs over ssh:
              before: 592ms
              after:  771ms +30% (+179ms)
      44f5acfb
  16. Jul 09, 2018
  17. Jul 06, 2018
  18. Jun 09, 2018
  19. Jul 08, 2018
  20. Jul 06, 2018
Loading