Closed cknight closed 4 months ago
After a recent hang (from a stable state, all I did was press Ctrl-W twice to select all text within a pair of quotes), all this output came at once after the editor became responsive again:
successfully cancelled request with ID: 241
client asked to cancel request 242, but no such pending request exists, ignoring
Unable to send result to client.
client asked to cancel request 246, but no such pending request exists, ignoring
client asked to cancel request 243, but no such pending request exists, ignoring
successfully cancelled request with ID: 248
client asked to cancel request 249, but no such pending request exists, ignoring
client asked to cancel request 247, but no such pending request exists, ignoring
client asked to cancel request 250, but no such pending request exists, ignoring
Unable to send result to client.
client asked to cancel request 251, but no such pending request exists, ignoring
client asked to cancel request 252, but no such pending request exists, ignoring
client asked to cancel request 253, but no such pending request exists, ignoring
client asked to cancel request 255, but no such pending request exists, ignoring
client asked to cancel request 254, but no such pending request exists, ignoring
client asked to cancel request 256, but no such pending request exists, ignoring
client asked to cancel request 257, but no such pending request exists, ignoring
successfully cancelled request with ID: 260
successfully cancelled request with ID: 261
successfully cancelled request with ID: 262
Unable to send result to client.
client asked to cancel request 258, but no such pending request exists, ignoring
Unable to send result to client.
client asked to cancel request 245, but no such pending request exists, ignoring
successfully cancelled request with ID: 266
successfully cancelled request with ID: 269
client asked to cancel request 263, but no such pending request exists, ignoring
client asked to cancel request 264, but no such pending request exists, ignoring
successfully cancelled request with ID: 270
client asked to cancel request 265, but no such pending request exists, ignoring
Unable to send result to client.
Unable to send result to client.
client asked to cancel request 267, but no such pending request exists, ignoring
successfully cancelled request with ID: 274
client asked to cancel request 271, but no such pending request exists, ignoring
client asked to cancel request 259, but no such pending request exists, ignoring
client asked to cancel request 272, but no such pending request exists, ignoring
client asked to cancel request 273, but no such pending request exists, ignoring
Unable to send result to client.
client asked to cancel request 275, but no such pending request exists, ignoring
client asked to cancel request 268, but no such pending request exists, ignoring
client asked to cancel request 278, but no such pending request exists, ignoring
successfully cancelled request with ID: 283
successfully cancelled request with ID: 284
successfully cancelled request with ID: 288
Unable to send result to client.
Unable to send result to client.
client asked to cancel request 287, but no such pending request exists, ignoring
Unable to send result to client.
successfully cancelled request with ID: 291
successfully cancelled request with ID: 293
successfully cancelled request with ID: 294
Unable to send result to client.
Unable to send result to client.
Unable to send result to client.
Downgrading to Deno 1.36.0 did not resolve the situation. Disabling the LSP stopped the hangs and CPU spikes (obviously not a solution)
Same here on Win 11. Renaming or moving a file causes LSP to hang for quite some time, then pops up an error about OOM, and shutting down! I've seen the same list of messages as above.
This is an inexpensive HP laptop with non-upgradable 8Gig memory. Started happening when Deno Upgrade to v1.37.0.
Also the laptop fan gets very load when this happens! I've never heard the fan on this new machine prior to this.
deno 1.37.0 (release, x86_64-pc-windows-msvc) v8 11.8.172.3 typescript 5.2.2
Downgraded to Deno 1.33.0, still hangs
If this is an LSP issue, would a Deno extension downgrade help?
It would if there was a bad interaction or issue with, say, the formatter or linter. I'll try downgrading the extension later tonight if that's possible.
In order to experience Bun, had installed WSL and the WSL extension in VS Code. I realize now that It was only after that that my LSP failures started. I suggest that WSL is a resource pig. No more LSP issues noticed now that I've removed WSL. I still wonder why LSP requires so much memory?
After removal of WSL I still have an issue! Renaming an 8.2mb file took more than 10 seconds. The IDE was unusable during this time. No crash or OOM was reported, but why would a file rename take such a long time?
This popup is open for more than 15 seconds on any filename change.
Is this normal?
Downgraded the extension to 3.22.0 and am still experiencing the issue..
After removal of WSL I still have an issue! Renaming an 8.2mb file took more than 10 seconds. The IDE was unusable during this time. No crash or OOM was reported, but why would a file rename take such a long time?
On rename attemps the language server asks the embedded ts server to look for imports that it can rename. I guess that's taking a really long time.
Do either of you have any large dependencies that I can try to reproduce this with? I think the large TS module graph that tsc has to work with in a Deno project might be a factor.
Do either of you have any large dependencies that I can try to reproduce this with? I think the large TS module graph that tsc has to work with in a Deno project might be a factor.
I'm working on a new'ish Fresh project, not very far into it, and I don't think I have any large dependencies. I've pushed my WIP code here if it helps: https://github.com/cknight/kv-explorer
I've rebooted. The LSP crashed on launch of VS Code. Restarted VS Code, and it was stable for a bit (as in I could actually use the LSP for now), though now it's hanging again. Found a new error in the Output, though I got this one during a period where the LSP wasn't hanging:
Unable to get completion info from TypeScript: Error: Debug Failure. Some exportInfo should match the specified exportMapKey
at Object.getImportCompletionAction (ext:deno_tsc/00_typescript.js:149303:13)
at getCompletionEntryCodeActionsAndSourceDisplay (ext:deno_tsc/00_typescript.js:158366:64)
at Object.getCompletionEntryDetails (ext:deno_tsc/00_typescript.js:158229:48)
at Object.getCompletionEntryDetails2 [as getCompletionEntryDetails] (ext:deno_tsc/00_typescript.js:142313:37)
at serverRequest (ext:deno_tsc/99_main_compiler.js:1100:27)
at [ext:cli/lsp/tsc.rs:4179:26]:1:12
After removal of WSL I still have an issue! Renaming an 8.2mb file took more than 10 seconds. The IDE was unusable during this time. No crash or OOM was reported, but why would a file rename take such a long time?
On rename attemps the language server asks the embedded ts server to look for imports that it can rename. I guess that's taking a really long time.
Do either of you have any large dependencies that I can try to reproduce this with? I think the large TS module graph that tsc has to work with in a Deno project might be a factor.
The project I'm working in is only about 25 files. total It has a single external dependency in deps.ts -- export { serve } from "https://deno.land/std@0.201.0/http/server.ts";
Is there a way for me to print the module graph? This happens in all projects great and small where Deno is enabled.
Why would an LSP, during a file name change need100% CPU and nearly 3Gig of memory?
Is there a way for me to print the module graph? This happens in all projects great and small where Deno is enabled.
deno info main.ts
will print your dependency tree, including sizes, etc.
@nayeemrmn PS C:\Users\nhron\dev\DB\NEW\NewDKV> deno info serve.ts local: C:\Users\nhron\dev\DB\NEW\NewDKV\serve.ts type: TypeScript dependencies: 6 unique size: 30.99KB
file:///C:/Users/nhron/dev/DB/NEW/NewDKV/serve.ts (1.11KB) ├─┬ file:///C:/Users/nhron/dev/DB/NEW/NewDKV/deps.ts (71B) │ └─┬ https://deno.land/std@0.201.0/http/server.ts (22.14KB) │ └── https://deno.land/std@0.201.0/async/delay.ts (1.71KB) ├── file:///C:/Users/nhron/dev/DB/NEW/NewDKV/constants.ts (2.07KB) ├─┬ file:///C:/Users/nhron/dev/DB/NEW/NewDKV/post.ts (557B) │ └── file:///C:/Users/nhron/dev/DB/NEW/NewDKV/constants.ts └─┬ file:///C:/Users/nhron/dev/DB/NEW/NewDKV/denoKvRPC.ts (3.35KB) └── file:///C:/Users/nhron/dev/DB/NEW/NewDKV/constants.ts
@nayeemrmn I've never used a Deno.json file, so I did deno init in this small project. It produced not only a deno.json file but also a deno.lock file shown below. How did this small project get so many dependencies? Some are extremely old -- std@0.156.0
{
"version": "3",
"remote": {
"https://deno.land/std@0.156.0/_util/assert.ts": "e94f2eb37cebd7f199952e242c77654e43333c1ac4c5c700e929ea3aa5489f74",
"https://deno.land/std@0.156.0/_util/os.ts": "3b4c6e27febd119d36a416d7a97bd3b0251b77c88942c8f16ee5953ea13e2e49",
"https://deno.land/std@0.156.0/path/_constants.ts": "df1db3ffa6dd6d1252cc9617e5d72165cd2483df90e93833e13580687b6083c3",
"https://deno.land/std@0.156.0/path/_interface.ts": "ee3b431a336b80cf445441109d089b70d87d5e248f4f90ff906820889ecf8d09",
"https://deno.land/std@0.156.0/path/_util.ts": "d16be2a16e1204b65f9d0dfc54a9bc472cafe5f4a190b3c8471ec2016ccd1677",
"https://deno.land/std@0.156.0/path/common.ts": "bee563630abd2d97f99d83c96c2fa0cca7cee103e8cb4e7699ec4d5db7bd2633",
"https://deno.land/std@0.156.0/path/glob.ts": "cb5255638de1048973c3e69e420c77dc04f75755524cb3b2e160fe9277d939ee",
"https://deno.land/std@0.156.0/path/mod.ts": "56fec03ad0ebd61b6ab39ddb9b0ddb4c4a5c9f2f4f632e09dd37ec9ebfd722ac",
"https://deno.land/std@0.156.0/path/posix.ts": "c1f7afe274290ea0b51da07ee205653b2964bd74909a82deb07b69a6cc383aaa",
"https://deno.land/std@0.156.0/path/separator.ts": "fe1816cb765a8068afb3e8f13ad272351c85cbc739af56dacfc7d93d710fe0f9",
"https://deno.land/std@0.156.0/path/win32.ts": "bd7549042e37879c68ff2f8576a25950abbfca1d696d41d82c7bca0b7e6f452c",
"https://deno.land/std@0.201.0/assert/assert.ts": "9a97dad6d98c238938e7540736b826440ad8c1c1e54430ca4c4e623e585607ee",
"https://deno.land/std@0.201.0/assert/assertion_error.ts": "4d0bde9b374dfbcbe8ac23f54f567b77024fb67dbb1906a852d67fe050d42f56",
"https://deno.land/std@0.201.0/async/debounce.ts": "adab11d04ca38d699444ac8a9d9856b4155e8dda2afd07ce78276c01ea5a4332",
"https://deno.land/std@0.201.0/async/delay.ts": "a6142eb44cdd856b645086af2b811b1fcce08ec06bb7d50969e6a872ee9b8659",
"https://deno.land/std@0.201.0/collections/_utils.ts": "5114abc026ddef71207a79609b984614e66a63a4bda17d819d56b0e72c51527e",
"https://deno.land/std@0.201.0/collections/deep_merge.ts": "9db788ba56cb05b65c77166b789e58e125dff159b7f41bf4d19dc1cba19ecb8b",
"https://deno.land/std@0.201.0/encoding/base64.ts": "144ae6234c1fbe5b68666c711dc15b1e9ee2aef6d42b3b4345bf9a6c91d70d0d",
"https://deno.land/std@0.201.0/flags/mod.ts": "0948466fc437f017f00c0b972a422b3dc3317a790bcf326429d23182977eaf9f",
"https://deno.land/std@0.201.0/fmt/bytes.ts": "f29cf69e0791d375f9f5d94ae1f0641e5a03b975f32ddf86d70f70fdf37e7b6a",
"https://deno.land/std@0.201.0/fmt/colors.ts": "87544aa2bc91087bb37f9c077970c85bfb041b48e4c37356129d7b450a415b6f",
"https://deno.land/std@0.201.0/http/etag.ts": "807382795850cde5c437c74bcc09392bc0fc56de348fc1271f383f4b28935b9f",
"https://deno.land/std@0.201.0/http/file_server.ts": "6f5c4a28c36995f31544abb49b86bee6e7a2d34664cac3936ff08ccad1682d85",
"https://deno.land/std@0.201.0/http/http_status.ts": "8a7bcfe3ac025199ad804075385e57f63d055b2aed539d943ccc277616d6f932",
"https://deno.land/std@0.201.0/http/server.ts": "1b2403b3c544c0624ad23e8ca4e05877e65380d9e0d75d04957432d65c3d5f41",
"https://deno.land/std@0.201.0/http/util.ts": "4cf044067febaa26d0830e356b0f3a5f76d701a60d7ff7a516fad7b192f4c3a7",
"https://deno.land/std@0.201.0/media_types/_db.ts": "7606d83e31f23ce1a7968cbaee852810c2cf477903a095696cdc62eaab7ce570",
"https://deno.land/std@0.201.0/media_types/_util.ts": "0879b04cc810ff18d3dcd97d361e03c9dfb29f67d7fc4a9c6c9d387282ef5fe8",
"https://deno.land/std@0.201.0/media_types/content_type.ts": "ad98a5aa2d95f5965b2796072284258710a25e520952376ed432b0937ce743bc",
"https://deno.land/std@0.201.0/media_types/format_media_type.ts": "f5e1073c05526a6f5a516ac5c5587a1abd043bf1039c71cde1166aa4328c8baf",
"https://deno.land/std@0.201.0/media_types/get_charset.ts": "18b88274796fda5d353806bf409eb1d2ddb3f004eb4bd311662c4cdd8ac173db",
"https://deno.land/std@0.201.0/media_types/parse_media_type.ts": "31ccf2388ffab31b49500bb89fa0f5de189c8897e2ee6c9954f207637d488211",
"https://deno.land/std@0.201.0/media_types/type_by_extension.ts": "daa801eb0f11cdf199445d0f1b656cf116d47dcf9e5b85cc1e6b4469f5ee0432",
"https://deno.land/std@0.201.0/media_types/vendor/mime-db.v1.52.0.ts": "6925bbcae81ca37241e3f55908d0505724358cda3384eaea707773b2c7e99586",
"https://deno.land/std@0.201.0/path/_basename.ts": "057d420c9049821f983f784fd87fa73ac471901fb628920b67972b0f44319343",
"https://deno.land/std@0.201.0/path/_constants.ts": "e49961f6f4f48039c0dfed3c3f93e963ca3d92791c9d478ac5b43183413136e0",
"https://deno.land/std@0.201.0/path/_dirname.ts": "355e297236b2218600aee7a5301b937204c62e12da9db4b0b044993d9e658395",
"https://deno.land/std@0.201.0/path/_extname.ts": "eaaa5aae1acf1f03254d681bd6a8ce42a9cb5b7ff2213a9d4740e8ab31283664",
"https://deno.land/std@0.201.0/path/_format.ts": "4a99270d6810f082e614309164fad75d6f1a483b68eed97c830a506cc589f8b4",
"https://deno.land/std@0.201.0/path/_from_file_url.ts": "6eadfae2e6f63ad9ee46b26db4a1b16583055c0392acedfb50ed2fc694b6f581",
"https://deno.land/std@0.201.0/path/_interface.ts": "6471159dfbbc357e03882c2266d21ef9afdb1e4aa771b0545e90db58a0ba314b",
"https://deno.land/std@0.201.0/path/_is_absolute.ts": "05dac10b5e93c63198b92e3687baa2be178df5321c527dc555266c0f4f51558c",
"https://deno.land/std@0.201.0/path/_join.ts": "815f5e85b042285175b1492dd5781240ce126c23bd97bad6b8211fe7129c538e",
"https://deno.land/std@0.201.0/path/_normalize.ts": "a19ec8706b2707f9dd974662a5cd89fad438e62ab1857e08b314a8eb49a34d81",
"https://deno.land/std@0.201.0/path/_os.ts": "d932f56d41e4f6a6093d56044e29ce637f8dcc43c5a90af43504a889cf1775e3",
"https://deno.land/std@0.201.0/path/_parse.ts": "0f9b0ff43682dd9964eb1c4398610c4e165d8db9d3ac9d594220217adf480cfa",
"https://deno.land/std@0.201.0/path/_relative.ts": "27bdeffb5311a47d85be26d37ad1969979359f7636c5cd9fcf05dcd0d5099dc5",
"https://deno.land/std@0.201.0/path/_resolve.ts": "7a3616f1093735ed327e758313b79c3c04ea921808ca5f19ddf240cb68d0adf6",
"https://deno.land/std@0.201.0/path/_to_file_url.ts": "a141e4a525303e1a3a0c0571fd024552b5f3553a2af7d75d1ff3a503dcbb66d8",
"https://deno.land/std@0.201.0/path/_to_namespaced_path.ts": "0d5f4caa2ed98ef7a8786286df6af804b50e38859ae897b5b5b4c8c5930a75c8",
"https://deno.land/std@0.201.0/path/_util.ts": "4e191b1bac6b3bf0c31aab42e5ca2e01a86ab5a0d2e08b75acf8585047a86221",
"https://deno.land/std@0.201.0/path/basename.ts": "bdfa5a624c6a45564dc6758ef2077f2822978a6dbe77b0a3514f7d1f81362930",
"https://deno.land/std@0.201.0/path/common.ts": "ee7505ab01fd22de3963b64e46cff31f40de34f9f8de1fff6a1bd2fe79380000",
"https://deno.land/std@0.201.0/path/dirname.ts": "b6533f4ee4174a526dec50c279534df5345836dfdc15318400b08c62a62a39dd",
"https://deno.land/std@0.201.0/path/extname.ts": "62c4b376300795342fe1e4746c0de518b4dc9c4b0b4617bfee62a2973a9555cf",
"https://deno.land/std@0.201.0/path/format.ts": "110270b238514dd68455a4c54956215a1aff7e37e22e4427b7771cefe1920aa5",
"https://deno.land/std@0.201.0/path/from_file_url.ts": "9f5cb58d58be14c775ec2e57fc70029ac8b17ed3bd7fe93e475b07280adde0ac",
"https://deno.land/std@0.201.0/path/glob.ts": "593e2c3573883225c25c5a21aaa8e9382a696b8e175ea20a3b6a1471ad17aaed",
"https://deno.land/std@0.201.0/path/is_absolute.ts": "0b92eb35a0a8780e9f16f16bb23655b67dace6a8e0d92d42039e518ee38103c1",
"https://deno.land/std@0.201.0/path/join.ts": "31c5419f23d91655b08ec7aec403f4e4cd1a63d39e28f6e42642ea207c2734f8",
"https://deno.land/std@0.201.0/path/mod.ts": "6e1efb0b13121463aedb53ea51dabf5639a3172ab58c89900bbb72b486872532",
"https://deno.land/std@0.201.0/path/normalize.ts": "6ea523e0040979dd7ae2f1be5bf2083941881a252554c0f32566a18b03021955",
"https://deno.land/std@0.201.0/path/parse.ts": "be8de342bb9e1924d78dc4d93c45215c152db7bf738ec32475560424b119b394",
"https://deno.land/std@0.201.0/path/posix.ts": "0a1c1952d132323a88736d03e92bd236f3ed5f9f079e5823fae07c8d978ee61b",
"https://deno.land/std@0.201.0/path/relative.ts": "8bedac226afd360afc45d451a6c29fabceaf32978526bcb38e0c852661f66c61",
"https://deno.land/std@0.201.0/path/resolve.ts": "133161e4949fc97f9ca67988d51376b0f5eef8968a6372325ab84d39d30b80dc",
"https://deno.land/std@0.201.0/path/separator.ts": "40a3e9a4ad10bef23bc2cd6c610291b6c502a06237c2c4cd034a15ca78dedc1f",
"https://deno.land/std@0.201.0/path/to_file_url.ts": "00e6322373dd51ad109956b775e4e72e5f9fa68ce2c6b04e4af2a6eed3825d31",
"https://deno.land/std@0.201.0/path/to_namespaced_path.ts": "1b1db3055c343ab389901adfbda34e82b7386bcd1c744d54f9c1496ee0fd0c3d",
"https://deno.land/std@0.201.0/path/win32.ts": "8b3f80ef7a462511d5e8020ff490edcaa0a0d118f1b1e9da50e2916bdd73f9dd",
"https://deno.land/std@0.201.0/streams/byte_slice_stream.ts": "c46d7c74836fc8c1a9acd9fe211cbe1bbaaee1b36087c834fb03af4991135c3a",
"https://deno.land/std@0.201.0/version.ts": "93ab592680d0d50d5269536653f52e2a446d85497e4d71a38e65de533093c040",
"https://deno.land/x/denoflate@1.2.1/mod.ts": "f5628e44b80b3d80ed525afa2ba0f12408e3849db817d47a883b801f9ce69dd6",
"https://deno.land/x/denoflate@1.2.1/pkg/denoflate.js": "b9f9ad9457d3f12f28b1fb35c555f57443427f74decb403113d67364e4f2caf4",
"https://deno.land/x/denoflate@1.2.1/pkg/denoflate_bg.wasm.js": "d581956245407a2115a3d7e8d85a9641c032940a8e810acbd59ca86afd34d44d",
"https://deno.land/x/esbuild@v0.17.11/mod.js": "4f4e61964a551d9c0baf5bb19e973cf631cf8c66ddaf01e70070f8a100fc938c",
"https://deno.land/x/esbuild_deno_loader@0.6.0/deps.ts": "fe86f62cb954edc2580868cdc3292d4446f22cd2c4eedbf8ee26513fdf74e343",
"https://deno.land/x/esbuild_deno_loader@0.6.0/mod.ts": "5d8a429b26c70f9fd522a8629e751f3bdf63680da473e537bc420d552ee3bf0b",
"https://deno.land/x/esbuild_deno_loader@0.6.0/src/deno.ts": "0e83ccabbe2b004389288e38df2031b79eb347df2d139fce9394d8e88a11f259",
"https://deno.land/x/esbuild_deno_loader@0.6.0/src/native_loader.ts": "343854a566cf510cf25144f7c09fc0c1097780a31830305142a075d12bb697ba",
"https://deno.land/x/esbuild_deno_loader@0.6.0/src/portable_loader.ts": "35b6c526eed8c2c781a3256b23c30aa7cce69c0ef1d583c15528663287ba18a3",
"https://deno.land/x/esbuild_deno_loader@0.6.0/src/shared.ts": "b64749cd8c0f6252a11498bd8758ef1220003e46b2c9b68e16da63fd7e92b13a",
"https://deno.land/x/importmap@0.2.1/_util.ts": "ada9a9618b537e6c0316c048a898352396c882b9f2de38aba18fd3f2950ede89",
"https://deno.land/x/importmap@0.2.1/mod.ts": "ae3d1cd7eabd18c01a4960d57db471126b020f23b37ef14e1359bbb949227ade",
"https://raw.githubusercontent.com/nhrones/Browser/master/browser.ts": "4c1cb8fb1feab5d33bf9af72a8c1ecae43abfef0f22bf95c503bd402f5277c1a"
}
}
I guess I really don't understand Deno.
Also, why would the LSP crawl all of this for a simple file name change?
This project has a /src/ folder that has ts files that get bundled to a /dist/ folder. I use my own dev server for this. Is this all included in the file name change?
The dev-server and it's dependencies are never referenced in this project, yet some of its dependencies are in this deno.lock?
For the record I don't think that's so many it would cause the problems mentioned in this issue -- I wouldn't put too much stock in my theory above.
How did this small project get so many dependencies? Some are extremely old -- std@0.156.0
The old std version is used by esbuild_deno_loader 0.6.0.
After removal of WSL I still have an issue! Renaming an 8.2mb file took more than 10 seconds. The IDE was unusable during this time. No crash or OOM was reported, but why would a file rename take such a long time?
@nhrones I missed the 8.2mb part -- that's a really large file! For example our 00_typescript.js
bundle is 8.1mb and is 174,000 LOC. I observed this behaviour on the regular node TS extension as well. So your case is behaving as expected.
I know it's unintuitive that the renamed file has to be scanned but I guess tsc needs to analyse the project holistically.
@nayeemrmn That's a json file with 100k user objects. The problem is, if I rename mod.ts with only several lines of code, it acts the same?
And now I can no longer enable deno in that project.
All values below are from TaskManager
When vsc opens this project with Deno disabled:
Visual Studio Code 401 MB
After a file name change 425 MB
When vsc opens this project with Deno enabled:
Visual Studio Code 2,220 MB
Deno:A secure runtime 1,759 MB
During a file name change
Visual Studio Code 4,427 MB
Deno:A secure runtime 2,899 MB
This high memory use stays this way for several minutes
never drops below
Visual Studio Code 3,370 MB
Deno:A secure runtime 2,213 MB
I've restarted my computer, and still can't get Deno enabled in this project? Any suggestions?
Okay @nhrones seems it alleviates the issue if you add the following to your VSCode settings:
{
"deno.enable": true,
"deno.disablePaths": ["<your_big_file_goes_here>.json"],
}
@nayeemrmn Yes! Thank you so much! Does this need to be an array of filePaths, or can I disable one or more folders?
"deno.disablePaths": ["./dist/"],
Does this need to be an array of filePaths, or can I disable one or more folders?
"deno.disablePaths": ["./dist/"],
You can, disabling dist
folder is an exemplary use case!
I can confirm this has solved my issues of moving and renaming files with deno enabled! Much thanks again. I was about to give up on Deno, but you've created a fan.
Seems that the excess memory being consumed was related to the large json data files. In the future I'll create a data folder, and disablePath
to it.
I've also disabled ./.vscode/
and a ./docs/
folder. This reduced memory consumption even more.
Again, Thanks for all your hard work.
This is still happening for me on Deno 1.37.1, however the output is somewhat different:
Starting Deno language server...
version: 1.37.1 (release, x86_64-unknown-linux-gnu)
executable: /home/chris/.deno/bin/deno
Connected to "Visual Studio Code" 1.82.2
Auto-resolved configuration file: "file:///home/chris/dev/deno/kv-explorer/deno.json"
Setting import map defined in configuration file: "file:///home/chris/dev/deno/kv-explorer/deno.json"
Resolved import map: "file:///home/chris/dev/deno/kv-explorer/deno.json"
Enabling import suggestions for: https://deno.land
Download https://deno.land/.well-known/deno-import-intellisense.json
Starting Deno language server...
version: 1.37.1 (release, x86_64-unknown-linux-gnu)
executable: /home/chris/.deno/bin/deno
Connected to "Visual Studio Code" 1.82.2
Auto-resolved configuration file: "file:///home/chris/dev/deno/kv-explorer/deno.json"
Setting import map defined in configuration file: "file:///home/chris/dev/deno/kv-explorer/deno.json"
Resolved import map: "file:///home/chris/dev/deno/kv-explorer/deno.json"
Enabling import suggestions for: https://deno.land
Server ready.
Unable to send result to client.
Unable to send result to client.
Unable to send result to client.
Unable to send result to client.
Unable to send result to client.
Unable to send result to client.
Unable to send result to client.
Unable to send result to client.
Unable to send result to client.
Unable to send result to client.
Unable to send result to client.
Unable to send result to client.
Unable to send result to client.
Unable to send result to client.
Unable to send result to client.
Unable to send result to client.
Unable to send result to client.
Unable to send result to client.
Unable to send result to client.
Unable to send result to client.
Unable to send result to client.
Unable to send result to client.
Unable to send result to client.
I'm not sure how true this holds as I've not had extensive time for development in the last day or so, but the LSP hangs primarily occurs in my types.ts file. The hang can sometimes be triggered by simply opening this file. The only major difference in this file compared to others in the project is that it has 13 exports?
Have you tried nayeemrmns fix above?
{
"deno.enable": true,
"deno.disablePaths": ["<your_file_goes_here>"],
}
I’m experiencing the same issues in a Deno project based on Slack’s starter template. There are no big files to ignore. I have to restart the language server pretty much every ~5 changes I make to a file.
Just tried to it with a fresh starter template and there I can’t reproduce the issue. Happy to provide my full codebase (via private message) to help see if the problem is reproducible for you, it’s still quite small.
Disabling paths didn't fix the issue for me either (I have no big files, but I put my types.ts file there). The issue comes and goes for me but is still an issue (Deno 1.37.1, LSP 3.25.1)
@cknight Do you use editor.formatOnSave
as well? I'm pretty confident it's caused by that. If you went without it for a while and it stopped happening I'd be interested in knowing.
@nayeemrmn I have not used this setting and it's currently disabled.
@cknight @eelco Is there a common resource constraint with us? I still get LSP failures after long edit sessions, where one or more dev-services are running (custom dev-server with esBuild and auto-refresh).
I'm om Windows11 with just 8Gig memory. My VS Code-Deno errors are usually OOM based.
I can always tell when it is about to happen as the laptop fan goes full speed!
I'm on 16GB Linux desktop and my issue is not memory related. I get 2 or more Deno LSP processes pegged at 100+% for a period of time during which the LSP is unresponsive. I do have auto-save on. For kicks, I've turned on editor.formatOnSave
to see if it makes things worse (so far, no), however, formatOnSave
doesn't run when a file is auto-saved, only when manually saved which I don't typically do. I've tried disabling all the code lens options and this reduced the hang time some, but only a little. I've also tried disabling GitHub Copilot extension which make no appreciable difference (hangs still occur).
@nhrones I am on a M1 Mac, 16GB RAM. No fan in my machine so I don’t get a warning 😉
I'm also facing a similar issue on my MacBook Air mid 2011(2gb ram, 4 cpus lubuntu), where a few minutes now seconds after I open the editor, the machine hangs and I have to forcefully turn it off and restart it again. Yeah I know it's an old machine but that's what I'm using in meantime while I get my MacBook Pro mid2012(8gb ram). I just installed the os yesterday and the only extension I have in vscode is deno and I try to only use vscode and the OS default terminal at the same time. The huge file I had was deno.lock which I deleted and disabled its generation. If I disable the deno extension then I can use it without any issue.
Just learned about the "Deno: Language Server Status" command in VSCode. I've run this while the system was idle for some time, saved the output, then triggered a CPU spike by visiting my types.ts file, which almost always triggers this, saved the new results, and finally captured the diff between the results of the idle status and CPU spike status. At issue is code_lens_resolve
action which is taking excessive time, though whether this is the cause or effect is unknown. Results as follows (idle on left, CPU spike on right):
Less interesting, but potentially relevant was also this difference at the very bottom (again, idle on left, CPU spike on right):
Based on the above, I've disabled the code lens with the following added to my workspace settings.json
file:
"editor.codeLens": false,
And wow! I can finally navigate quickly with no hangs. Types show up instantly when hovering. Clearly my issue is around the code lens. Very early days, but I'll leave it disabled for now and report back if it doesn't fully "fix" my issue. Happy to turn it back on if any additional testing is required.
@cknight After applying "editor.codeLens": false, everything in VSCode is fast and crisp on my slow laptop. Thanks for this!
Thanks @cknight, this is very helpful!
Looks like it's the parse we do to collect tests. I think we should only have test code lens on
Actually it's on _test.ts
files for starters.code_lens_resolve()
, and that shouldn't be doing anything intensive, or it shouldn't be called at all unless you have deno.codeLens.{references,implementations}
on...
@cknight Can you share your workspace settings shown in the status page?
@nayeemrmn Sure. Here is my full status output (for another project with code lens still enabled):
And for the project I've had most issues with (with code lens disabled):
Just a question, because it looks strange to me: deno require 2 instance of lsp, while rust (for example) use just an instance for working. I mean, why? (I tried to kill and them get restarted)
Is there any update about this bug? I in the latest deno version (v1.38.3), VScode is still very slow when formatOnSave.
But when I used v1.36.4 again, the problem all disappeared.
What exactly happened with 1.37 and 1.38, to cause this lag?
Just a question, because it looks strange to me: deno require 2 instance of lsp, while rust (for example) use just an instance for working. I mean, why? (I tried to kill and them get restarted)
@danielecr there should only a single instance of an LSP in a given project. Could you share your set up where you see two instances?
Is there any update about this bug? I in the latest deno version (v1.38.3), VScode is still very slow when formatOnSave.
But when I used v1.36.4 again, the problem all disappeared.
What exactly happened with 1.37 and 1.38, to cause this lag?
We have a meeting tomorrow about this problem @ynwd. Will get back to you on this.
FYI, I've tried re-enabling the code lens on my project and the issue still persists (CPU spikes and the LSP is frozen). I'm on Deno 1.38.3 and VSCode Deno extension 3.28. I have only a single LSP instance running.
Possibly related to https://github.com/denoland/deno/issues/20136
Recently I'm having frequent CPU spikes and the LSP hangs preventing me from interacting with the editor which is highly frustrating.
Output
The editor will hang and eventually spit out a number of output lines, sometimes 2 ("successfully..." and "Unable...") sometimes more.
Versions
vscode: 1.82.2 deno: 1.37.0 extension: occurs on both the latest 3.24.0 and the previous version (3.23.1?) os: Linux Mint 21