rust hg status

[Valentin Gatien-Baron]

Hello,

I wrote a fraction of hg status in rust, just the minimum needed to
compare current revision and working copy with few of the flags and
config settings supported. As you can imagine, the goal was better
performance.  Before trying to upstream bits of this, I figured I'd
check there's interest for this change in particular, or this kind
of changes in general (I suspect rust would bring significant
improvements to hg cat or hg files). The rest of this mail is more
details.

While the implementation doesn't handle every uncommon situation right
and could use some serious cleanup, it's an interesting performance
improvement. In a repository with 100k tracked files and 500k ignored
files, in the best case and measuring on a good machine:

- hg-rs st takes ~50ms
- hg-rs st -mard takes ~14ms
- hg-rs st -u takes ~39ms

By contrast, hg+chg+fsmonitor's best case is 110ms regardless of
flags. Without fsmonitor, we're talking about 2.4s for hg st or hg st
-u, and 400ms for hg st -mard. As a baseline, hg st --syntax-error
takes 12ms.

A ratio of x2 compared with fsmonitor+chg is nice, but while neither
best case is what you get all the time, fsmonitor degrades pretty
badly, oftentimes in hard to understand ways, making for an
unpredictable experience that is frequently bad.
Say you change the hgignore, the rust version will take 300ms, the
fsmonitor version will take 4.4s (I think 2s timeout + 2.4s regular
status).
Say you remove a directory at the root of the repository, 50ms rust
vs 4.4s fsmonitor.
Say you haven't used a particular share in some time, you may well see
1s rust vs 4.4s fsmonitor.

So I think there's a lot of value in having status without fsmonitor
going much faster:
- increase significantly the scale at which fsmonitor is needed
- improve the bad cases of fsmonitor (or even the fast path depending
on how things are made to work together)

Regards,

Valentin Gatien-Baron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20190215/57995d1e/attachment.html>