all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Dmitry Gutov <dmitry@gutov.dev>
To: Spencer Baugh <sbaugh@janestreet.com>
Cc: 74243@debbugs.gnu.org, Sean Whitton <spwhitton@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	[thread overview]
Message-ID: <48e27733-61a8-49d2-94b2-109c98b3dd7f@gutov.dev> (raw)
In-Reply-To: <ieriks9fu5l.fsf@janestreet.com>

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.





  reply	other threads:[~2024-11-27  0:18 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-07 17:41 bug#74243: [PATCH] Speed up vc-hg-state by treating ignored files as unregistered Spencer Baugh via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-11-17  1:03 ` Sean Whitton
     [not found]   ` <ierttc3z71g.fsf@janestreet.com>
2024-11-26  7:52     ` Sean Whitton
2024-11-26 23:26       ` Dmitry Gutov
2024-11-26 23:32         ` Spencer Baugh via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-11-27  0:18           ` Dmitry Gutov [this message]
2024-11-29  8:17             ` Sean Whitton
2024-11-29 12:43               ` Spencer Baugh via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-11-29 23:45                 ` Sean Whitton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48e27733-61a8-49d2-94b2-109c98b3dd7f@gutov.dev \
    --to=dmitry@gutov.dev \
    --cc=74243@debbugs.gnu.org \
    --cc=sbaugh@janestreet.com \
    --cc=spwhitton@spwhitton.name \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.