hg-core: add function timing information This change makes use of the newly added logging infrastructure to trace the execution time of some important calls. This approach is very much complementary to using a profiler and will not guard against out-of-order execution or other kinds of compiler optimizations. That said, it is useful to get a rough high-level idea of where time is spent. Differential Revision: https://phab.mercurial-scm.org/D8253

rust: add logging utils This change adds the `log` crate, the community-approved logging facade backed by Rust core developers as well as the logging-consumer crate `simple_logger` to build a foundation for logging from Rust. Using this setup allows us to choose how to log depending on the way `hg-core` is used: if it's within the context of `hg-cpython`, we might not want to use it the same way as with a direct cli for example. Differential Revision: https://phab.mercurial-scm.org/D8252

rust-status: traverse working directory in parallel Using `rayon` for this task ensures that we are using the same work-stealing threadpool for everything. This change introduces `crossbeam` as an explicit dependency, although it is already a dependency of `rayon`. It provides better structures for multi-threaded tasks than the stdlib. Differential Revision: https://phab.mercurial-scm.org/D8251

rust-status: wrap `stat_dmap_entries` to ease profiling Differential Revision: https://phab.mercurial-scm.org/D8250

rust-status: refactor handling of unknown files Differential Revision: https://phab.mercurial-scm.org/D8249

rust-status: move to recursive traversal to prepare for parallel traversal I have looked into traversing the working directory in parallel either by a recursive or an iterative algorithm. The recursive approach won quite decisively both in terms of performance and code readability. You can look at my experiment here: https://heptapod.octobus.net/Alphare/rayon-recursive-traversal The chance of a stack overflow happening because the directories get too nested seems slim. This change does not yet do anything in parallel. Differential Revision: https://phab.mercurial-scm.org/D8215

rust-pathauditor: use interior mutability for use in multi-threaded contexts The usual recommendation for using `RwLock` or `Mutex` is that if there are about as many write as there are reads, use `Mutex`, and if there are more reads than writes, use `RwLock`. If after the main bottleneck (i.e. parallel traversal) is removed this shows up on profiles, we should investigate using the `parking_lot` since we don't need a poisoning API, or maybe move to different types of caches entirely. Differential Revision: https://phab.mercurial-scm.org/D8213

rust-pathauditor: actually populate the `audited_dirs` cache I forgot this when rewriting this logic during the review process. Differential Revision: https://phab.mercurial-scm.org/D8212

rust-pathauditor: actually split Windows shortname aliases at `~` Right now, splitting with a max of 1 parts is useless. Differential Revision: https://phab.mercurial-scm.org/D8211

debuginstall: add entry about re2 Rust bindings when applicable Differential Revision: https://phab.mercurial-scm.org/D8226

rust-cpython: add `debug` module to expose debug information to Python This will be mostly used in `debuginstall`. Differential Revision: https://phab.mercurial-scm.org/D8225

rust-status: use bare hg status fastpath from Python This change also adds a test case for subrepos. Repeating the benchmark information from the `hg-core` commit: On the Netbeans repository: C: 840ms Rust+C: 556ms Mozilla Central with the one pattern that causes a fallback removed: C: 2.315s Rust+C: 1.700s Differential Revision: https://phab.mercurial-scm.org/D7931

rust-status: update rust-cpython bridge to account for the changes in core Differential Revision: https://phab.mercurial-scm.org/D7930

rust-status: add bare `hg status` support in hg-core A lot of performance remains to be gained, most notably by doing more things in parallel, but also by caching, not falling back to Python but switching to another regex engine, etc.. I have measured on multiple repositories that this change, when in combination with the next two patches, improve bare `hg status` performance, and has no observable impact when falling back (because it does so early). On the Netbeans repository: C: 840ms Rust+C: 556ms Mozilla Central with the one pattern that causes a fallback removed: C: 2.315s Rust+C: 1.700 s Differential Revision: https://phab.mercurial-scm.org/D7929