Request: Asynchronous completion backend #61
Labels
Comments
Well, there's only so much we can do on eglot's side to "speed up" completions. We can't really speed them up, only keep the interface as responsible as possible while we frantically make requests and hope the responses arrive in time. In that sense, even with
This may or not be what your example is doing (I didn't fully understand it), but is the only way. I have tested this approach successfully in a common Lisp IDE called SLY. See its In short, this is more than probably more correctly implemented in |
joaotavora
added a commit
that referenced
this issue
Aug 9, 2018
|
Hi @jojojames Can you try the commit I pushed to a temporary branch and tell me if it improves things for you? There are two things that I hope you could comment on:
Thanks in advance. João |
Yes. Much faster than before. I think it improves on both cold/warm completions (I guess when the completions aren't cached yet). It's much more noticeable on the cold/non-cached completions where the version on master branch of eglot pauses for half a second before continuing. I think flymake-mode stalls the completion a little too. I did a quick eyeball-test disabling/enabling flymake-mode and it seems more smooth without flymake-mode on. The stall seems to happen as it shows the error/warning indicators in the fringe. I don't have any special flymake settings but could get your more info if that would help.
Nothing that bothers me here. |
OK, good. Can you tell me which server you are using?
Flymake-mode isn't really connected to completions. More importantly flymake only kicks in when you have stopped typing after a little while. Indeed, the processing after receiving a lot of diagnostics is non-trivial, so that may explain the delay you see. However I need to see more than an eyeball test. Can you describe or show a controlled experiment? I need
Alternatively, you can use the profiler |
|
I tried out this branch also (if I didn't mess up).
I have a big monorepo (unfortunately I can't share) which I tried to run a simple completion, first completion takes about 15 seconds. Next one takes between 1-2 seconds. I will see if I can find something smaller with similar issue. This is the profile output if it helps: |
|
Thanks for the profiler data. It does help: there are some things that stand out.
(defun jsonrpc--log-event (_connection _message &optional type)
"A NOOP just for issue 61"
nil) |
|
Thanks, this seems to have improved the situation, I disabled the flyspell and also added that function override: This is the new output: |
Great. The profile looks saner now. How noticeable would you say the improvement is (time cut in 50%? 25%?). Anyway, I'm going to turn off logging by default (at least for this server). |
|
Hard to say, now when I keep trying it is hard to tell, since it is a bit inconsistent. Sometimes it felt somewhat useable and then when I retry from scratch it turns out it to have similar issues. Still not useable in this project (which has 8000 js files), the completion makes the keys lag slower than you can type and freezes. But I tried a smaller project and there it was quite quick, not impacting the typing experience. The worst part is the initial completion when it gets the first list since you connected to the eglot server, then it freezes for a few seconds. But perhaps 25% was the general feeling, I have to do some more investigation, perhaps with most packages disabled, to make the profiling less horrendous. |
Hmmm, the commit I had earlier is supposed to fix exactly these freezes.
Yes this would be welcome. A test project where I can witness these effects myself is also useful. |
|
So the "snappy company" fix is now in master. Please try it out, but notice that it requires a new jsonrpc.el version. When MELPA updates it in a few hours it should sort this detail automatically. Tomorrow I will reanalyse the logging-related slowdown and provide a fix to that too (possibly disabling all logging by default). |
Cquery, I need to try this out with the kotlin-langserver I am playing with too but I'm guessing both would work about the same.
I agree, I think it kicks in quite often for me though, (at least it seems that way). Not sure.
cquery, window.c in emacs' codebase. I just type random characters in any of the functions and notice it.
Once, I find some time, I'll try and give better diagnostics (understandably, the above is kindof hand-wavy :)) and create a new thread for this topic. |
|
@joaotavora I can report back that it is working much better now, the speed of the completion is still about the same, but it is not blocking the character input which was the thing that really made it hard to use. I don't think I got it to load the new branch version properly, must have been the old code. Will double check the load-path next time. Sorry for the inconvenience and thanks for the fix. |
Great. That is precisely the intended effect. |
You can control how often it kicks in though. See the docstring of
Thanks. Don't you need some kind of compilation database?
Good idea. Thanks. |
Thanks, I'll take a look. Maybe that will be enough.
I use to generate the compilation database. |
bhankas
pushed a commit
to bhankas/emacs
that referenced
this issue
Sep 18, 2022
This should improve company-capf's performance. * eglot.el (Package-Requires): Require jsonrpc 1.0,1 (eglot-completion-at-point): Use completion-table-dynamic. Pass CANCEL-ON-INPUT to jsonrpc-request.
bhankas
pushed a commit
to bhankas/emacs
that referenced
this issue
Sep 19, 2022
This should improve company-capf's performance. * eglot.el (Package-Requires): Require jsonrpc 1.0,1 (eglot-completion-at-point): Use completion-table-dynamic. Pass CANCEL-ON-INPUT to jsonrpc-request.
bhankas
pushed a commit
to bhankas/emacs
that referenced
this issue
Sep 19, 2022
This should improve company-capf's performance. * eglot.el (Package-Requires): Require jsonrpc 1.0,1 (eglot-completion-at-point): Use completion-table-dynamic. Pass CANCEL-ON-INPUT to jsonrpc-request. #61: joaotavora/eglot#61
jollaitbot
pushed a commit
to sailfishos-mirror/emacs
that referenced
this issue
Oct 12, 2022
This should improve company-capf's performance. * eglot.el (Package-Requires): Require jsonrpc 1.0,1 (eglot-completion-at-point): Use completion-table-dynamic. Pass CANCEL-ON-INPUT to jsonrpc-request. GitHub-reference: close joaotavora/eglot#61
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi, thanks for the package!
Working with completion-at-point/company-capf, it seems like completions are being done synchronously. Playing around with Emacs' codebase (window.c) and cquery, it seems there is slight lag/stutter when typing.
I gave a shot here but it seems too slow (typing latency is faster but completions take a while to return?) to be useable.
The text was updated successfully, but these errors were encountered: