Skip to content
Snippets Groups Projects
  1. Sep 13, 2018
    • Matt Harbison's avatar
      cext: stop preprocessing a partial function call · c06c585f
      Matt Harbison authored
      MSVC++ 14 yelled:
      
          mercurial/cext/revlog.c(1913): fatal error C1057: unexpected end of file in
                                         macro expansion
      
      At this point, the C extensions build (with warnings), and it dies in win32.py
      because the `_fields_` strings in the ctypes classes are being converted to
      bytes by the source translator.
      c06c585f
    • Matt Harbison's avatar
      py3: add b'' to some setup.py strings for Windows · ec68135a
      Matt Harbison authored
      These were things found trying to do `make PYTHON="py -3" local`.  The following
      is dumped out, before dying while compiling the C extensions:
      
      C:\Program Files\Python37\lib\site-packages\setuptools\dist.py:406: UserWarning:
        The version specified (b'4.7.1') is an invalid version, this may not work as
        expected with newer versions of setuptools, pip, and PyPI. Please see PEP 440
        for more details.
        "details." % self.metadata.version
      running build_py
      byte-compiling .\mercurial\thirdparty\concurrent\futures\_base.py to _base.cpython-37.pyc
        File "mercurial\thirdparty\concurrent\futures\_base.py", line 416
          raise exception_type, self._exception, self._traceback
                              ^
      SyntaxError: invalid syntax
      
      # skip-blame since these are just converting to bytes literals
      ec68135a
    • Augie Fackler's avatar
    • Gregory Szorc's avatar
      hg: don't reuse repo instance after unshare() · c5e6c1ba
      Gregory Szorc authored
      Unsharing a repository is a pretty invasive procedure and fundamentally
      changes the behavior of the repository.
      
      Currently, hg.unshare() calls into localrepository.__init__ to
      re-initialize the repository instance. This is a bit hacky. And
      future commits that refactor how localrepository instances are
      constructed will make this difficult to support.
      
      This commit changes unshare() so it constructs a new repo instance
      once the unshare I/O has completed. It then poisons the old repo
      instance so any further use will result in error.
      
      Surprisingly, nothing in core appears to access a repo instance
      after it has been unshared!
      
      .. api::
      
         ``hg.unshare()`` now poisons the repo instance so it can't be used.
      
         It also returns a new repo instance suitable for interacting with
         the unshared repository.
      
      Differential Revision: https://phab.mercurial-scm.org/D4557
      c5e6c1ba
  2. Sep 12, 2018
    • Gregory Szorc's avatar
      unionrepo: dynamically create repository type from base repository · 23f2299e
      Gregory Szorc authored
      This is basically the same thing we just did for bundlerepo except
      for union repositories.
      
      .. api::
      
         ``unionrepo.unionrepository()`` is no longer usable on its own.
      
         To instantiate an instance, call ``unionrepo.instance()`` or
         ``unionrepo.makeunionrepository()``.
      
      Differential Revision: https://phab.mercurial-scm.org/D4556
      23f2299e
    • Gregory Szorc's avatar
      bundlerepo: dynamically create repository type from base repository · 335ae4d0
      Gregory Szorc authored
      Previously, bundlerepository inherited from localrepo.localrepository.
      You simply instantiated a bundlerepository and its __init__ called
      localrepo.localrepository.__init__. Things were simple.
      
      Unfortunately, this strategy is limiting because it assumes that
      the base repository is a localrepository instance. And it assumes
      various properties of localrepository, such as the arguments its
      __init__ takes. And it prevents us from changing behavior of
      localrepository.__init__ without also having to change derived classes.
      
      Previous and ongoing work to abstract storage revealed these
      limitations.
      
      This commit changes the initialization strategy of bundle repositories
      to dynamically create a type to represent the repository. Instead of
      a static type, we instantiate a new local repo instance via
      localrepo.instance(). We then combine its __class__ with
      bundlerepository to produce a new type. This ensures that no matter
      how localrepo.instance() decides to create a repository object, we
      can derive a bundle repo object from it. i.e. localrepo.instance()
      could return a type that isn't a localrepository and it would "just
      work."
      
      Well, it would "just work" if bundlerepository's custom implementations
      only accessed attributes in the documented repository interface. I'm
      pretty sure it violates the interface contract in a handful of
      places. But we can worry about that another day. This change gets us
      closer to doing more clever things around instantiating repository
      instances without having to worry about teaching bundlerepository about
      them.
      
      .. api::
      
         ``bundlerepo.bundlerepository`` is no longer usable on its own.
      
         The class is combined with the class of the base repository it is
         associated with at run-time.
      
         New bundlerepository instances can be obtained by calling
         ``bundlerepo.instance()`` or ``bundlerepo.makebundlerepository()``.
      
      Differential Revision: https://phab.mercurial-scm.org/D4555
      335ae4d0
    • Gregory Szorc's avatar
      bundlerepo: factor out code for instantiating a bundle repository · a8d2faec
      Gregory Szorc authored
      This code will soon become a bit more complicated. So extract to its
      own function.
      
      And change both instantiators of bundlerepository to use it.
      
      Differential Revision: https://phab.mercurial-scm.org/D4554
      a8d2faec
    • Gregory Szorc's avatar
      bundlerepo: pass create=True · 2d2bbf3f
      Gregory Szorc authored
      I don't want to know how this came to be. Maybe a holdover from the
      days before Python had a bool type?
      
      Differential Revision: https://phab.mercurial-scm.org/D4553
      2d2bbf3f
    • Gregory Szorc's avatar
      shelve: use bundlerepo.instance() to construct a repo object · 84d6e9a2
      Gregory Szorc authored
      The instance() functions are preferred over cls.__init__ for
      creating repo instances. It doesn't really matter now. But future
      commits will refactor the bundlerepository class in ways that will
      cause the old way to break.
      
      Differential Revision: https://phab.mercurial-scm.org/D4552
      84d6e9a2
  3. Jul 29, 2018
  4. Sep 13, 2018
  5. Sep 10, 2018
    • Boris Feld's avatar
      revlog: reuse cached delta for identical base revision (issue5975) · a911932d
      Boris Feld authored
      Since 8f83a953dddf, we skip over empty deltas when choosing a delta base. Such
      delta happens when two distinct revisions have the same content.
      
      The remote might be sending a delta against such revision within the bundle.
      In that case, the delta base is no longer considered, but the cached one could
      still, be used with the equivalent revision.
      
      Not reusing the delta from the bundle can have a significant performance
      impact, so we now make sure with doing so when possible.
      a911932d
    • Boris Feld's avatar
      snapshot: fix line order when skipping over empty deltas · bdb41eaa
      Boris Feld authored
      The code movement in 37957e07138c introduced an error.
      
      Since 8f83a953dddf, we discarded some revisions because they are identical to
      their delta base (and use that delta base instead). That logic is good,
      however, in 37957e07138c we mixed up the order of two line, adding the "new"
      revision to the set of already tested one, instead of the discarded one. So in
      practice, we were never investigating any revisions in a chain starting with
      an empty delta. Creating significantly worst delta chain (eg: Mercurial's
      manifest move goes from about 60MB up to about 80MB).
      bdb41eaa
  6. Sep 13, 2018
  7. Aug 21, 2018
  8. Sep 12, 2018
  9. Sep 13, 2018
  10. Sep 12, 2018
  11. Jul 29, 2018
  12. Jun 07, 2018
  13. Sep 01, 2018
    • Yuya Nishihara's avatar
      109b2c2d
    • Yuya Nishihara's avatar
      formatter: fill missing resources by formatter, not by resource mapper · ee1e74ee
      Yuya Nishihara authored
      While working on demand loading of ctx/fctx objects, I found it's weird
      to support lookup in both directions. For instance, fctx can be loaded
      from (ctx, path) pair, but ctx may also be derived from fctx.changectx()
      in the original mapping. If the original mapping has had fctx but no ctx,
      and if the new mapping provides {path}, we can't be sure if fctx should be
      updated by fctx'.changectx()[path] or not.
      
      This patch simply drops the support for the resolution in fctx -> ctx -> repo
      direction.
      ee1e74ee
  14. Jun 07, 2018
  15. Sep 10, 2018
  16. Sep 12, 2018
  17. Sep 10, 2018
  18. Sep 04, 2018
  19. Sep 07, 2018
    • Gregory Szorc's avatar
      util: update lrucachedict order during get() · 8f2c0d1b
      Gregory Szorc authored
      get() should have the same semantics as __getitem__ for item
      retrieval.
      
      Differential Revision: https://phab.mercurial-scm.org/D4506
      8f2c0d1b
    • Gregory Szorc's avatar
      util: lower water mark when removing nodes after cost limit reached · f296c0b3
      Gregory Szorc authored
      See the inline comment for the reasoning here. This is a pretty
      common strategy for garbage collectors, other cache-like primtives.
      
      The performance impact is substantial:
      
      $ hg perflrucachedict --size 4 --gets 1000000 --sets 1000000 --mixed 1000000 --costlimit 100
      ! inserts w/ cost limit
      ! wall 1.659181 comb 1.650000 user 1.650000 sys 0.000000 (best of 7)
      ! wall 1.722122 comb 1.720000 user 1.720000 sys 0.000000 (best of 6)
      ! mixed w/ cost limit
      ! wall 1.139955 comb 1.140000 user 1.140000 sys 0.000000 (best of 9)
      ! wall 1.182513 comb 1.180000 user 1.180000 sys 0.000000 (best of 9)
      
      $ hg perflrucachedict --size 1000 --gets 1000000 --sets 1000000 --mixed 1000000 --costlimit 10000
      ! inserts
      ! wall 0.679546 comb 0.680000 user 0.680000 sys 0.000000 (best of 15)
      ! sets
      ! wall 0.825147 comb 0.830000 user 0.830000 sys 0.000000 (best of 13)
      ! inserts w/ cost limit
      ! wall 25.105273 comb 25.080000 user 25.080000 sys 0.000000 (best of 3)
      ! wall  1.724397 comb  1.720000 user  1.720000 sys 0.000000 (best of 6)
      ! mixed
      ! wall 0.807096 comb 0.810000 user 0.810000 sys 0.000000 (best of 13)
      ! mixed w/ cost limit
      ! wall 12.104470 comb 12.070000 user 12.070000 sys 0.000000 (best of 3)
      ! wall  1.190563 comb  1.190000 user  1.190000 sys 0.000000 (best of 9)
      
      $ hg perflrucachedict --size 1000 --gets 1000000 --sets 1000000 --mixed 1000000 --costlimit 10000 --mixedgetfreq 90
      ! inserts
      ! wall 0.711177 comb 0.710000 user 0.710000 sys 0.000000 (best of 14)
      ! sets
      ! wall 0.846992 comb 0.850000 user 0.850000 sys 0.000000 (best of 12)
      ! inserts w/ cost limit
      ! wall 25.963028 comb 25.960000 user 25.960000 sys 0.000000 (best of 3)
      ! wall  2.184311 comb  2.180000 user  2.180000 sys 0.000000 (best of 5)
      ! mixed
      ! wall 0.728256 comb 0.730000 user 0.730000 sys 0.000000 (best of 14)
      ! mixed w/ cost limit
      ! wall 3.174256 comb 3.170000 user 3.170000 sys 0.000000 (best of 4)
      ! wall 0.773186 comb 0.770000 user 0.770000 sys 0.000000 (best of 13)
      
      $ hg perflrucachedict --size 100000 --gets 1000000 --sets 1000000 --mixed 1000000 --mixedgetfreq 90 --costlimit 5000000
      ! gets
      ! wall 1.191368 comb 1.190000 user 1.190000 sys 0.000000 (best of 9)
      ! wall 1.195304 comb 1.190000 user 1.190000 sys 0.000000 (best of 9)
      ! inserts
      ! wall 0.950995 comb 0.950000 user 0.950000 sys 0.000000 (best of 11)
      ! inserts w/ cost limit
      ! wall 1.589732 comb 1.590000 user 1.590000 sys 0.000000 (best of 7)
      ! sets
      ! wall 1.094941 comb 1.100000 user 1.090000 sys 0.010000 (best of 9)
      ! mixed
      ! wall 0.936420 comb 0.940000 user 0.930000 sys 0.010000 (best of 10)
      ! mixed w/ cost limit
      ! wall 0.882780 comb 0.870000 user 0.870000 sys 0.000000 (best of 11)
      
      This puts us ~2x slower than caches without cost accounting. And for
      read-heavy workloads (the prime use cases for caches), performance is
      nearly identical.
      
      In the worst case (pure write workloads with cost accounting enabled),
      we're looking at ~1.5us per insert on large caches. That seems "fast
      enough."
      
      Differential Revision: https://phab.mercurial-scm.org/D4505
      f296c0b3
Loading