##// END OF EJS Templates
upstream » mercurial-mirror
RSS

Clone from https://www.mercurial-scm.org/repo/hg-all

dirstate-tree: Avoid BTreeMap double-lookup when inserting a dirstate entry...
dirstate-tree: Avoid BTreeMap double-lookup when inserting a dirstate entry The child nodes of a given node in the tree-shaped dirstate are kept in a `BTreeMap` where keys are file names as strings. Finding or inserting a value in the map takes `O(log(n))` string comparisons, which adds up when constructing the tree. The `entry` API allows finding a "spot" in the map that may or may not be occupied and then access that value or insert a new one without doing map lookup again. However the current API is limited in that calling `entry` requires an owned key (and so a memory allocation), even if it ends up not being used in the case where the map already has a value with an equal key. This is still a win, with 4% better end-to-end time for `hg status` measured here with hyperfine: ``` Benchmark #1: ../hg2/hg status -R $REPO --config=experimental.dirstate-tree.in-memory=1 Time (mean ± σ): 1.337 s ± 0.018 s [User: 892.9 ms, System: 437.5 ms] Range (min … max): 1.316 s … 1.373 s 10 runs Benchmark #2: ./hg status -R $REPO --config=experimental.dirstate-tree.in-memory=1 Time (mean ± σ): 1.291 s ± 0.008 s [User: 853.4 ms, System: 431.1 ms] Range (min … max): 1.283 s … 1.309 s 10 runs Summary './hg status -R $REPO --config=experimental.dirstate-tree.in-memory=1' ran 1.04 ± 0.02 times faster than '../hg2/hg status -R $REPO --config=experimental.dirstate-tree.in-memory=1' ``` * ./hg is this revision * ../hg2/hg is its parent * $REPO is an old snapshot of mozilla-central Differential Revision: https://phab.mercurial-scm.org/D10550
Simon Sapin -
r47886:04bcba53 default
Show More
Name Size Modified Last Commit Author
/ rust / hgcli
.cargo
src
Cargo.lock Loading ...
Cargo.toml Loading ...
README.md Loading ...
build.rs Loading ...
pyoxidizer.bzl Loading ...

Oxidized Mercurial

This project provides a Rust implementation of the Mercurial (hg)
version control tool.

Under the hood, the project uses
PyOxidizer to embed a Python
interpreter in a binary built with Rust. At run-time, the Rust fn main()
is called and Rust code handles initial process startup. An in-process
Python interpreter is started (if needed) to provide additional
functionality.

Building

This project currently requires an unreleased version of PyOxidizer
(0.7.0-pre). For best results, build the exact PyOxidizer commit
as defined in the pyoxidizer.bzl file:

$ git clone https://github.com/indygreg/PyOxidizer.git
$ cd PyOxidizer
$ git checkout <Git commit from pyoxidizer.bzl>
$ cargo build --release

Then build this Rust project using the built pyoxidizer executable::

$ /path/to/pyoxidizer/target/release/pyoxidizer build

If all goes according to plan, there should be an assembled application
under build/<arch>/debug/app/ with an hg executable:

$ build/x86_64-unknown-linux-gnu/debug/app/hg version
Mercurial Distributed SCM (version 5.3.1+433-f99cd77d53dc+20200331)
(see https://mercurial-scm.org for more information)

Copyright (C) 2005-2020 Olivia Mackall and others
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Running Tests

To run tests with a built hg executable, you can use the --with-hg
argument to run-tests.py. But there's a wrinkle: many tests run custom
Python scripts that need to import modules provided by Mercurial. Since
these modules are embedded in the produced hg executable, a regular
Python interpreter can't access them! To work around this, set PYTHONPATH
to the Mercurial source directory. e.g.:

$ cd /path/to/hg/src/tests
$ PYTHONPATH=`pwd`/.. python3.7 run-tests.py \
    --with-hg `pwd`/../rust/hgcli/build/x86_64-unknown-linux-gnu/debug/app/hg