8000 configurable debouncing delays · Issue #327 · typescript-language-server/typescript-language-server · GitHub
[go: up one dir, main page]
Skip to content

configurable debouncing delays #327

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
strager opened this issue Dec 8, 2021 · 5 comments
Open

configurable debouncing delays #327

strager opened this issue Dec 8, 2021 · 5 comments
Labels
enhancement

Comments

@strager
Copy link
strager commented Dec 8, 2021

TypeScript's LSP server has an artificial 200 ms debounce/delay:

typescript-language-server/src/lsp-server.ts

Line 316 in bb1c105

readonly doRequestDiagnosticsDebounced = debounce(() => this.doRequestDiagnostics(), 200);

and an artificial 50 ms debounce/delay:

typescript-language-server/src/diagnostic-queue.ts

Lines 30 to 33 in bb1c105

protected readonly firePublishDiagnostics = debounce(() => {
const diagnostics = this.getDiagnostics();
this.publishDiagnostics({ uri: this.uri, diagnostics });
}, 50);

I think this hard-coded delay makes TypeScript's LSP server look bad when compared to other LSP servers: https://quick-lint-js.com/benchmarks/

I think the delay should be user-configurable (e.g. disable-able or a custom delay).
@rchl
Copy link
Member
rchl commented Dec 8, 2021 •
edited
Loading

I'm open to tweaking that but I don't necessarily agree with that site that faster is better in that case.

When typing the code, it is very often invalid until the user finished the statement or a line. So showing errors very quickly just results in flickering error highlights while the user is typing. Having a bigger delay mitigates that.

The editor I'm using (Sublime Text) even applies an additional delay (when there are no diagnostics visible already) itself for that reason.

@rchl
Copy link
Member
rchl commented Dec 8, 2021 •
edited
Loading

It appears that the methodology of that site is to open a document and wait for the diagnostics to appear. That could be a case we could optimize for and just trigger the diagnostics as soon as possible. But I would argue that it would have fairly little value in the real world besides making such artificial benchmark look better.

EDIT: Ops, didn't read the whole thing. It actually measures how fast diagnostics are shown after editing the file.

@strager
Copy link
Author
strager commented Dec 8, 2021

[...] I don't necessarily agree with that site that faster is better in that case.

When typing the code, it is very often invalid until the user finished the statement or a line. So showing errors very quickly just results in flickering error highlights while the user is typing. Having a bigger delay mitigates that.

I personally want my tools (including error squigglies and syntax highlighting) to instantly respond to my keystrokes.

I think it is a matter of preference.

I don't necessarily agree with that site that faster is better in that case.

Ideally there'd also be benchmarks for other metrics, such as power consumption. This would be more realistic and not subject to preference (as much). (Artificial delays wouldn't affect power consumption as much. In fact, they might improve power consumption, as less work needs to be done.)

@David-Else
Copy link

Neovim just got 150ms debounce built in to the nightly neovim/neovim#16908 for the LSP.

Better to have it user-configurable here I think.

@rchl rchl 89DC added the enhancement label Jan 20, 2022
@rchl rchl mentioned this issue Jan 26, 2022
Open
@mjlbach
Copy link
mjlbach commented Feb 24, 2022

Neovim just got 150ms debounce built in to the nightly neovim/neovim#16908 for the LSP.

Note, our delay is configurable. Empirically 150 ms seems to be lower than other editors/lsp plugins, so we thought it was a safe choice.

@yioneko yioneko mentioned this issue Dec 30, 2022
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@strager @rchl @David-Else @mjlbach
0