Language-tools: Habilitar o recurso de tokens semânticos em arquivos grandes faz com que o Language Server fique inusualmente lento

Criado em 18 jan. 2021 · 4Comentários · Fonte: sveltejs/language-tools

Descreva o bug

O plugin VS Code Svelte v104.0.0 introduziu suporte para Semantic Tokens. Por padrão, está habilitado:

// The default
"svelte.plugin.typescript.semanticTokens.enable": true

... No entanto, isso leva a uma desaceleração significativa em .svelte arquivos onde um elemento <script lang="ts"> consiste em uma grande quantidade de TypeScript (no meu caso, 2.600 linhas). O Language Server deixa de responder efetivamente, com a verificação de tipo demorando mais de um minuto e as dicas de ferramentas congelando em "Carregando ..." indefinidamente.

Reproduzir

Com o plugin VS Code Svelte v104.0.0 instalado e a opção padrão de "svelte.plugin.typescript.semanticTokens.enable": true aplicada, crie um arquivo .svelte com, digamos, 2.600 linhas de código TypeScript. Deliberadamente crie um erro de tempo de compilação e observe como toda verificação de tipo leva muito tempo para responder.

Você pode atualizar as configurações para "svelte.plugin.typescript.semanticTokens.enable": false e vê-lo instantaneamente responsivo novamente. Não há necessidade de reiniciar o Language Server, nem reiniciar o VS Code, para observar a mudança.

Comportamento esperado

.svelte arquivos contendo scripts TypeScript devem permanecer responsivos, não importa o tamanho dos scripts, e nenhuma configuração extra pelo desenvolvedor deve ser necessária para manter o desempenho utilizável.

Sistema (preencha as seguintes informações):

SO: macOS 10.15.7
IDE: VS Code 1.52.1
Plugin / pacote: "Svelte para VSCode"

Contexto adicional

Conforme discutido com @dummdidumm no Svelte Discord em #language-tools . Para a atenção de @ jasonlyu123.

De @dummdidumm em Discord:

dummdidumm: Sim, os tokens semânticos podem ser lentos em arquivos grandes, especialmente porque precisamos fazer muitos mapeamentos de mapas de origem
dummdidumm: @ jasonlyu09 talvez devêssemos adicionar alguns limites para arquivos / intervalos grandes, essencialmente não fazendo a solicitação se o intervalo solicitado para analisar se tornar muito grande. Acho que o VS Code faz algo semelhante.

Fixed bug

Fonte

shirakaba

Todos 4 comentários

Sim, a extensão de digitação do VSCode limitou-o a 100.000. Mas eu achei ainda muito lento para nós, talvez por causa do mapeamento de origem, acho que o limitaria a 50000;

jasonlyu123 em 19 jan. 2021

Sim, a extensão de digitação do VSCode limitou-o a 100.000. Mas eu achei ainda muito lento para nós, talvez por causa do mapeamento de origem, acho que o limitaria a 50000;

@ jasonlyu123 100.000 de quê? Meu arquivo de 2.600 linhas tem 128.292 caracteres, então, se deveria desabilitar os Tokens Semânticos para arquivos com mais de 100.000 caracteres, parecia que não o fazia de forma alguma.

Porém, se for sobre o comprimento de algum arquivo gerado (seu PR menciona TSX, então talvez seja), ao invés da própria fonte, eu não sei qual é o comprimento de meus arquivos gerados.

shirakaba em 19 jan. 2021

Caracteres, se o arquivo js / ts exceder esse caractere, a extensão do texto digitado não processará os tokens semânticos completos do arquivo. Tentei o número na extensão esbelta no modo de depuração e ainda parece ser muito lento.

Existem vários tipos de solicitações de token semântico que o servidor de linguagem pode implementar. Atualmente, implementamos extensão de texto tipo range e full-file como. Do meu entendimento, parece que o vscode tentará obter apenas os resultados variados quando o arquivo completo não estiver disponível. E o intervalo um é o motivo pelo qual você verá uma mudança repentina de cor ao rolar para baixo no documento.

jasonlyu123 em 19 jan. 2021

👍1

Agora está limitado. Vamos agora se ele pode ser usado novamente ao ativar os tokens semânticos.