Loading React types cripples LSP performance

[chrisabrams]

Version: Deno 1.43.1

I was excited by the snappy performance of the LSP in VS Code for version 1.43 however as soon as you load React's types the 10+ second processing time resumes. This is the culprit from what I can tell:

// @deno-types="npm:@types/react@18"

Removing that will resume the snappy performance, but neither Deno nor VS Code know what React's types are.

I am unable to get the LSP to recognize the types this way:

import type {} from "npm:@types/react"

I've created a sample repo for reference: https://github.com/chrisabrams/lsp-react-slow

I saw there is a new option jsxImportSourceTypes from #23419 for 1.43 but when I tried adding that, VS Code was not aware of the types. For example here is what I did:

    "jsx": "react-jsx",
    "jsxImportSource": "react",
    "jsxImportSourceTypes": "@types/react"

With the import_map.json referencing their respective npm package.

Here is the language server performance:

Performance (last 3 000 entries)

Name	Count	Duration
lsp.cache	1	924.945ms
lsp.code_action	23	3939.941ms
lsp.code_lens	9	0.004ms
lsp.did_change	6	2.159ms
lsp.did_close	2	0.216ms
lsp.did_open	3	6.837ms
lsp.document_highlight	4	2.9ms
lsp.document_symbol	13	4641.626ms
lsp.folding_range	6	10074.431ms
lsp.formatting	2	1.506ms
lsp.get_navigation_tree	13	4641.57ms
lsp.goto_definition	2	8.457ms
lsp.hover	12	4.21ms
lsp.initialize	1	100.348ms
lsp.semantic_tokens_full	6	15289.446ms
lsp.semantic_tokens_range	2	482.885ms
lsp.signature_help	1	7.711ms
lsp.testing_update	12	0.836ms
lsp.update_cache	1	0ms
lsp.update_diagnostics_deps	12	0.585ms
lsp.update_diagnostics_lint	11	4.242ms
lsp.update_diagnostics_ts	7	13193.018ms
lsp.update_registries	1	2.8ms
tsc.host.$getAssets	1	39.371ms
tsc.host.$getDiagnostics	9	10348.348ms
tsc.host.$getSupportedCodeFixes	1	0.565ms
tsc.host.cleanupSemanticCache	1	0.135ms
tsc.host.getApplicableRefactors	26	1.521ms
tsc.host.getCodeFixesAtPosition	4	3.465ms
tsc.host.getCompletionsAtPosition	1	7.243ms
tsc.host.getDefinitionAndBoundSpan	2	7.98ms
tsc.host.getDocumentHighlights	4	2.527ms
tsc.host.getEncodedSemanticClassifications	8	47.704ms
tsc.host.getNavigationTree	9	2.074ms
tsc.host.getOutliningSpans	6	3.364ms
tsc.host.getQuickInfoAtPosition	9	4.933ms
tsc.host.getSignatureHelpItems	1	7.5ms
tsc.op.op_is_node_file	89	0.001ms
tsc.op.op_load	30	1.507ms
tsc.op.op_resolve	35	1.081ms
tsc.op.op_script_names	4	1.29ms
tsc.op.op_script_version	6	0.013ms
tsc.op.op_ts_config	2	0.007ms
tsc.request.$getAssets	1	41.539ms
tsc.request.$getSupportedCodeFixes	1	26.45ms
tsc.request.cleanupSemanticCache	1	2.807ms
tsc.request.getApplicableRefactors	23	3939.074ms
tsc.request.getCodeFixesAtPosition	4	3.716ms
tsc.request.getDefinitionAndBoundSpan	2	8.198ms
tsc.request.getDocumentHighlights	4	2.759ms
tsc.request.getEncodedSemanticClassifications	8	11587.728ms
tsc.request.getNavigationTree	9	6704.443ms
tsc.request.getOutliningSpans	6	10074.374ms
tsc.request.getQuickInfoAtPosition	9	5.287ms
tsc.request.getSignatureHelpItems	1	7.638ms

[nathanwhit]

Hello! I started looking into this and I can definitely reproduce the issue (thanks for the nice and small repo illustrating the problem!)

The majority of the time is being spent in the typescript compiler, particularly typechecking the call to React.createElement here.

I don't have a proper fix at this time, but as a workaround you can add an any type assertion to shortcircuit typechecking for that call like in this commit (chrisabrams/lsp-react-slow@85bd67f). That should make the LSP usable for you again in the meantime.