Risk for bad performance

[jrieken]

We have identified[1] this extension as being a possible cause for high load on the extension host. I'd suggest to optimise this part of the provideCompletionItems-function. With very large documents there is potential for bad perf because the whole document is first scanned for /**...*/-blocks (until one includes the cursor-position). Instead I'd advise to take the current cursor position and from there walk left until you see /** and walk right until you see */.

[1] How do we know? The extension host must send a ping every 250ms to the main thread. If that doesn't happen 4 times in a row we send a telemetry event containing the ids of all active extensions. Those lists of ids we analyse to find extensions that occur over and over again.

[HookyQR]

Hey @jrieken. Is it safe to say this extension can be deleted now because of the capability in v1.10?

[jrieken]

Sad, but actually yes. We leverage TypeScript service smartness and have now shipped a first version on which we will build more features.

[HookyQR]

Nah, it's a good thing. On less for me to look after. 😉

[evanwarner]

@HookyQR I'd encourage you to keep going with this plugin for the time being. The native JSDoc functionality is not an adequate substitute for this plugin yet. In order to get the native autocomplete, I need to set:

"[javascript]": {
   "editor.quickSuggestions": {
     "comments": true
   }
 }

Which means I get suggestions for every. word. I. type. in. my. documentation. Really annoying.

Also, the native functionality just autocompletes the tag name, it doesn't add the boilerplate or tabstops for things like {type} description.