GNU bug report logs - #74243
[PATCH] Speed up vc-hg-state by treating ignored files as unregistered

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: 74243 <at> debbugs.gnu.org, Sean Whitton <spwhitton <at> spwhitton.name>
Subject: bug#74243: [PATCH] Speed up vc-hg-state by treating ignored files as unregistered
Date: Wed, 27 Nov 2024 02:18:39 +0200

On 27/11/2024 01:32, Spencer Baugh wrote:

>> A user option seems like an easier choice.
>>
>> Solutions that clear cache under some conditions or other tend to be
>> more complex, and slow down at least some combined scenarios (e.g. one
>> of my use cases is saving the buffer and having diff-hl-mode use its
>> vc state from after-save-hook).
> 
> These are all reasonable concerns.
> 
> Since posting my original patch, though, I've heard from Hg developers
> that they plan to eventually implement per-directory ignore files, like
> in Git.  That would remove the original performance problem, so maybe
> this is not so important.

That's good to hear.

> That being said, it's still sad that the vc hooks in find-file-hook and
> after-save-hook can hurt performance so much.

Understandable, that's what drove me to implement that older change in 
Git back then.

> It seems to me that the ideal outcome would be to support asynchronicity
> in those hooks.  That would benefit all vc backends... though this is
> perhaps quite difficult.

The most complex part could be retaining a compatible/synchronous API.

> Maybe asynchronously populating the saved vc-state property would work?
> With some clever usage of nil return values as Sean describes...

Maybe Sean's idea is better, but to spitball different options:

- FWIW since not too long ago we've treated a similar issue in diff-hl 
by using a thread - which calls the same code inside (meaning the 
current synchronous implementation), but it happens in the background, 
so the input is unfrozen and the visual update is asynchronous.

But keeping in mind that threads' error handling is not great, so it 
seems not optimal to keep a lot of implementation code inside a thread. 
Also, threads are reportedly not good with remote calls yet.

- The mode-line update isn't going to wait asynchronously, though, but 
perhaps an update could be scheduled. If state updates are not 
synchronous, I suppose this would also need some debouncing/queueing 
mechanism for the callers as well. That is the route of migrating to a 
different calling convention, though.

- Finally, if the main scenario that we are concerned is the use in 
vc-dir, we could try switching only its updates to another backend call. 
E.g. vc-dir-resynch-file would switch to the (possibly) more precise - 
though slower - dir-status-files, just like the code that first 
populates that buffer. vc-state could then afford shortcuts more safely.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.