rust hg status

[Valentin Gatien-Baron]

Somewhat related:

I was looking in emacs's version control support for hg (they run into a
bug with hg parent with evolve,
https://lists.gnu.org/archive/html/bug-gnu-emacs/2019-07/msg00349.html) and
noticed that they have both a parser for the dirstate and for the hgignore,
written in elisp, for speed:
https://github.com/emacs-mirror/emacs/blob/f744797af1dd73a547dd204d7e79f084e6508517/lisp/vc/vc-hg.el#L582-L1053
,
https://github.com/emacs-mirror/emacs/commit/de76a167dc09dc695a5acebabb7ab354a6bf556e
! And
elisp is not exactly known to be fast.

I looked in vc-git quickly, and they don't seem to do this sort of things,
so I think they'd use hg status -A file, if it was faster. The commit
message mentions large repos, but that seems weird as they call hg status
-A file, which should not be very dependent on repo size. But regardless of
whether it's cost of status in large repos or startup cost, they both get
improved the more rust there is in hg status.

In short: one more reason for putting rust in status, given the non trivial
lengths that hg users go to otherwise.

On Fri, Feb 15, 2019 at 2:39 PM Valentin Gatien-Baron <
vgatien-baron at janestreet.com> wrote:

> 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/20190715/ae5acef4/attachment.html>