Skip to content
Snippets Groups Projects
  1. Oct 14, 2018
  2. Oct 13, 2018
  3. Oct 14, 2018
  4. Oct 15, 2018
  5. Oct 08, 2018
    • Georges Racinet's avatar
      rust: rustlazyancestors.__contains__ · 72b94f94
      Georges Racinet authored
      This changeset provides a Rust implementation of
      the iteration performed by lazyancestor.__contains__
      
      It has the advantage over the Python iteration to use
      the 'seen' set encapsuled into the dedicated iterator (self._containsiter),
      rather than storing emitted items in another set (self._containsseen),
      and hence should reduce the memory footprint.
      
      Also, there's no need to convert intermediate emitted revisions back into
      Python integers.
      
      At this point, it would be tempting to implement the whole lazyancestor object
      in Rust, but that would lead to more C wrapping code (two objects) for
      little expected benefits.
      72b94f94
  6. Oct 14, 2018
  7. Sep 27, 2018
    • Georges Racinet's avatar
      rust: hooking into Python code · 9cadb0f5
      Georges Racinet authored
      We introduce a new class called 'rustlazyancestors'
      in the ancestors module, which is used only if
      parsers.rustlazyancestors does exist.
      
      The implementation of __contains__ stays unchanged,
      but is now backed by the Rust iterator. It would
      probably be a good candidate for further development,
      though, as it is mostly looping, and duplicates the
      'seen' set.
      
      The Rust code could be further optimized, however it already
      gives rise to performance improvements:
      
      median timing from hg perfancestors:
      - on pypy:
          before: 0.077566s
          after:  0.016676s -79%
      - on mozilla central:
          before: 0.190037s
          after:  0.082225s -58%
      - on a private repository (about one million revisions):
          before: 0.567085s
          after:  0.108816s -80%
      - on another private repository (about 400 000 revisions):
          before: 1.440918s
          after:  0.290116s -80%
      
      median timing for hg perfbranchmap base
      - on pypy:
          before:  1.383413s
          after:   0.507993s -63%
      - on mozilla central:
          before:  2.821940s
          after:   1.258902s -55%
      - on a private repository (about one million revisions):
          before: 77.065076s
          after:   16.158475s -80%
      - on another private repository (about 401 000 revisions):
          before:  7.835503s
          after:   3.545331s -54%
      9cadb0f5
  8. Oct 14, 2018
  9. Oct 12, 2018
  10. Oct 13, 2018
  11. Oct 12, 2018
  12. Oct 13, 2018
  13. Oct 14, 2018
  14. Oct 06, 2018
  15. Oct 07, 2018
  16. Oct 06, 2018
    • Yuya Nishihara's avatar
      rust-chg: depend on log and tokio_timer · 7623199d
      Yuya Nishihara authored
      I'll start porting the daemon management functions from chg of C, which
      will be difficult to debug without some logging facility. AFAIK, the log
      crate is easy-to-use and widely used.
      
      tokio_timer provides sleep() helper to be used while spawning a server
      process.
      7623199d
  17. Oct 07, 2018
  18. Oct 14, 2018
  19. Oct 13, 2018
  20. Oct 14, 2018
  21. Sep 27, 2018
    • Georges Racinet's avatar
      rust: exposing in parsers module · 3b275f54
      Georges Racinet authored
      To build with the Rust code, set the HGWITHRUSTEXT
      environment variable.
      
      At this point, it's possible to instantiate and use
      a rustlazyancestors object from a Python interpreter.
      
      The changes in setup.py are obviously a quick hack,
      just good enough to test/bench without much
      refactoring. We'd be happy to improve on that with
      help from the community.
      
      Rust bindings crate gets compiled as a static library,
      which in turn gets linked within 'parsers.so'
      
      With respect to the plans at
      https://www.mercurial-scm.org/wiki/OxidationPlan
      this would probably qualify as "roll our own FFI".
      Also, it doesn't quite meet the target of getting
      rid of C code, since it brings actually more, yet:
      
      - the new C code does nothing else than parsing
        arguments and calling Rust functions.
        In particular, there's no complex allocation involved.
      - subsequent changes could rewrite more of revlog.c, this
        time resulting in an overall decrease of C code and
        unsafety.
      3b275f54
    • Georges Racinet's avatar
      rust: iterator bindings to C code · a36c5e23
      Georges Racinet authored
      In this changeset, still made of Rust code only,
      we expose the Rust iterator for instantiation and
      consumption from C code.
      
      The idea is that both the index and index_get_parents()
      will be passed from the C extension, hence avoiding a hard
      link dependency to parsers.so, so that the crate can
      still be built and tested independently.
      
      On the other hand, parsers.so will use the symbols
      defined in this changeset.
      a36c5e23
    • Georges Racinet's avatar
      rust: pure Rust lazyancestors iterator · dbc28c91
      Georges Racinet authored
      This is the first of a patch series aiming to provide an
      alternative implementation in the Rust programming language
      of the _lazyancestorsiter from the ancestor module.
      
      This iterator has been brought to our attention by the people at
      Octobus, as a potential good candidate for incremental "oxydation"
      (rewriting in Rust), because it has shown performance issues lately
      and it merely deals with ints (revision numbers) obtained by calling
      the index, whih should be directly callable from Rust code,
      being itself implemented as a C extension.
      
      The idea behind this series is to provide a minimal example of Rust code
      collaborating with existing C and Python code. To open the way to gradually
      rewriting more of Mercurial's Python code in Rust, without being forced to pay
      a large initial cost of rewriting the existing fast core into Rust.
      
      This patch does not introduce any bindings to other Mercurial code
      yet. Instead, it introduces the necessary abstractions to address the problem
      independently, and unit-test it.
      
      Since this is the first use of Rust as a Python module within Mercurial,
      the hg-core crate gets created within this patch. See its Cargo.toml for more
      details.
      
      Someone with a rustc/cargo installation may chdir into rust/hg-core and
      run the tests by issuing:
      
         cargo test --lib
      
      The algorithm is a bit simplified (see details in docstrings),
      and at its simplest becomes rather trivial, showcasing that Rust has
      batteries included too: BinaryHeap, the Rust analog of Python's heapq
      does actually all the work.
      
      The implementation can be further optimized and probably be made more
      idiomatic Rust.
      dbc28c91
  22. Oct 14, 2018
  23. Oct 13, 2018
    • Matt Harbison's avatar
      tests: replace `cd ..` with an absolute path in a couple ssh tests · 52b773f5
      Matt Harbison authored
      These tests are broken under py3 on Windows to the point where the `cd ..` was
      actually escaping into the system wide $TEMP.  The subsequent `hg init` created
      a repo there, and then added a local extension to the hgrc.  This breaks every
      single subsequent test when it tries to `hg init` in its $TESTTMP, and can't
      load the localwrite.py extension.  And since I botched this the first time and
      replaced the wrong `cd ..`, this just replaces all of them.  I've noticed test
      garbage in $TEMP recently, and maybe this will help.
      
      Perhaps `hg init` shouldn't load the config for the local repo, but this is an
      easy enough workaround for now.
      52b773f5
Loading