GNU bug report logs - #77588
Catastrophic slowdown in eglot via `flymake-diag-region'

Previous Next

Full log

Message #37 received at 77588 <at> debbugs.gnu.org (full text, mbox):

From: João Távora <joaotavora <at> gmail.com>
To: JD Smith <jdtsmith <at> gmail.com>
Cc: Spencer Baugh <sbaugh <at> janestreet.com>, Eli Zaretskii <eliz <at> gnu.org>,
 77588 <at> debbugs.gnu.org
Subject: Re: bug#77588: Catastrophic slowdown in eglot via
 `flymake-diag-region'
Date: Tue, 08 Apr 2025 22:00:22 +0100

[I dropped the bug report and previous recipients, adding them back and
hoping they can piece together the context from the quotations]

JD Smith <jdtsmith <at> gmail.com> writes:

>> Btw your html mails are hard to read.
>
> This is hopefully better.

Yes it is, thanks!

>> On Apr 8, 2025, at 12:44 PM, João Távora <joaotavora <at> gmail.com> wrote:
>> 
>> 
>> On Tue, Apr 8, 2025, 17:24 JD Smith <jdtsmith <at> gmail.com> wrote
>> 
>> Then it might be worth switching the test to `(not (eq ...' from `(/= ...'.
>> 
>> I don't see why. = Is the lisp way of comparing things we know are numbers.
>
> You just mentioned one of them can be nil though...

Right, but the patch I pushed checks for that before using `/=`.

>> My point is that the message's version info is an explicit
>> acknowledgement that the information may be out of date by the time
>> the client processes it.  I see no way around that (other than
>> everything working quicker).
>> 
>> What could be the server's rationale for sending out of date
>> information when it _knows_ that the information is out of date?
>> Presumably we the client have informed it of the new version in
>> didChange. Or am I missing something?
>
> Maybe I am missing something, but if the push diagnostics and
> didChange cross paths, I could see how the latter could be out of
> date.

Indeed, but they don't cross paths, at least not on virtually all
servers that I know of.  Servers on a "push diagnostics" model operate
by sending at most 1 publishDiagnostics notification _after_ receiiving
a didChange.  Which makes sense.  You're notified of some changes V1,
you do some calculations, and you publish your results.  If you operate
asynchronously and during that time you get another notification of
changes V2, you probably have throw most work out (certainly don't
publish it).

If you supply the Eglot events log to your server session we can check
what's happening.  I have used basedpyright+eglot in the past though,
and I never noticed any problems (doesn't mean they can't or weren't
happening under the hood, but I certainly didn't experience any
catastrophic slowdown).

João

Previous Next

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