bug#63470: [PATCH] Use faster option for running vc-hg status

[Spencer Baugh <sbaugh@janestreet.com>]

Dmitry Gutov <dmitry@gutov.dev> writes:
> On 16/05/2023 23:39, Spencer Baugh wrote:
>> Eli Zaretskii<eliz@gnu.org>  writes:
>> 
>>>> Date: Fri, 12 May 2023 23:10:05 +0300
>>>> Cc:63470@debbugs.gnu.org
>>>> From: Dmitry Gutov<dmitry@gutov.dev>
>>>>
>>>> On 12/05/2023 22:57, Spencer Baugh wrote:
>>>>> I could add a user option to revert to the old behavior, if you want.
>>>> We could cache it like we do with vc-git--program-version. That's a
>>>> simple memoization that doesn't take the host into account (though that
>>>> could be implemented, too).
>>> Yes, that'd be a good-enough solution.
>>>
>>>> But it'd really make things easier if we're just allowed to rely on some
>>>> new enough versions of Git and Hg.
>>> It isn't easy to be backward-compatible, but we should strive at doing
>>> that.
>> OK, revised backwards-compatible patch attached.
>> 
>
> Thanks! It does look better, performance-wise.
>
> Would you say that the performance of project--vc-list-files could be
> similarly improved for Hg? Or does the Rust implementation in question
> already get used for 'hg status .', as long as there is no "re:"
> involved?

As of very recently in Mercurial trunk, yes, the Rust implementation
will be used for project--vc-list-files.  (It only just got support for
-0)

Although note: currently the Rust implementation doesn't support "hg
status somefile"; that will fall back to the Python implementation.  So
"hg status ." would be slow, actually, but "hg status" (as
project--vc-list-files inexplicably seems to do, despite passing "." for
file-or-list, based on inspecting with (vc-edit-next-command)) is fast.

(either way though, I'm working on making "hg status somefile" work in
Rust, since that will make vc-hg-state fast)