deno: lsp: Autocompletion and error highlighting too slow while working with some files in VSCode
Working on some files in VSCode using Deno plugin turns really slow on some scenarios. Overall, almost all files become slow to work on, but some are way slower than others. Seems like importing some external dependency worsens the problem.
I have other projects in Deno, and none of them have this behavior. Maybe the only difference is the amount of dependencies, but anyway, doesn’t explain completely the slowness for me, seems like too much.
Here’s a video to show how slow it can become, working on the following folder: https://github.com/sirikon/bilbostack-app/tree/2ddb90f4cb7c7392b2083858f0b585f1fcc04f26/back opening file src/web/server.ts.
https://user-images.githubusercontent.com/1157382/149842369-aae47ab5-a312-48d8-9d7b-ee462746477d.mp4
Here is the output that can be shown below when enabled using "deno.internalDebug": true: Download
deno --version
deno 1.17.3 (release, x86_64-unknown-linux-gnu)
v8 9.7.106.15
typescript 4.5.2
VSCode deno plugin: v3.10.1
VSCodium (It’s just VSCode without Microsoft telemetry):
Version: 1.63.2
Commit: 899d46d82c4c95423fb7e10e68eba52050e30ba3
Date: 2021-12-17T00:20:01.675Z
Electron: 13.5.2
Chromium: 91.0.4472.164
Node.js: 14.16.0
V8: 9.1.269.39-electron.0
OS: Linux x64 5.10.0-10-amd64
Running on Debian 11 Bullseye
About this issue
- Original URL
- State: open
- Created 2 years ago
- Reactions: 3
- Comments: 15 (5 by maintainers)
Are there any updates on this? Working with the Deno analyser/formatter/linter is extremely frustrating due to just how unbelievably slow it is, similar to what the author of this issue is experiencing, if not worse. I’d expect analysis to be instantaneous, meanwhile it currently takes ~2-3 seconds for anything to happen on-screen, often even longer. It’s a real annoyance for development.
I laughed when I saw this, my project has 1613 documents, maybe Deno is for small projects only? The slow response time of the LSP is the most frustrating issue I’ve encountered in Deno development. Now I just uninstall vscode_deno and pretend I’m developing a Node.js + TypeScript project.
Thanks for following up!
That is the domain/feature of TypeScript type checker (
tsc) which is embedded in Deno. It obviously uses internal information about how many types it is checking and how long that takes, where we can only “observe” and in that sense it is unlikely we will get it “correct”, as it might be a slow machine or someone unavoidably has a large type system and they just suffer with it, so it is likely something we will continue to just lettsc“worry” about, while we focus on streamlining things around it.You highlighted a couple of perf issues (though obviously they weren’t the root cause of this issue) that we should address mentioned above, so will keep it open for that reason.
Hey @cknight I upgraded, and removed code lens. I noticed its marginally quicker. (Previously if i was typing “const variableName” i would get a red line saying " “c” not found" that wouldnt ever go away unless i did a VC Windows Reload. With the new update it actually does go away).
But whats still not working is there’s no intelisense when it comes to auto imports.
Granted. I could just not have it configured properly…
Deno Language Server Status
Workspace Settings
Workspace Details
Documents in memory: 938
Performance measures: 3000
Performance
Same. I love the concept of Deno and think it can really get adopted, but the actual DX has been killing me. Its so so slow.
Deno Language Server Status
Workspace Settings
Workspace Details
Documents in memory: 882
Performance measures: 3000
Performance