Language-tools: Habilitar la función de tokens semánticos en archivos grandes hace que el servidor de idiomas sea inusualmente lento

Creado en 18 ene. 2021 · 4Comentarios · Fuente: sveltejs/language-tools

Describe el error

El complemento VS Code Svelte v104.0.0 introdujo soporte para Semantic Tokens. De forma predeterminada, esto está habilitado:

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

... Sin embargo, esto conduce a una desaceleración significativa en los archivos .svelte donde un elemento <script lang="ts"> consta de una gran cantidad de TypeScript (en mi caso, 2600 líneas). El servidor de idiomas deja de responder de manera efectiva, la verificación de tipos tarda un minuto y la información sobre herramientas se congela en "Cargando ..." indefinidamente.

Reproducir

Con el complemento VS Code Svelte v104.0.0 instalado y la opción predeterminada "svelte.plugin.typescript.semanticTokens.enable": true aplicada, cree un archivo .svelte con, digamos, 2600 líneas de código TypeScript. Cree deliberadamente un error en tiempo de compilación y observe cómo toda la verificación de tipos tarda mucho en responder.

Puede actualizar la configuración a "svelte.plugin.typescript.semanticTokens.enable": false y ver cómo responde instantáneamente nuevamente. No es necesario reiniciar el servidor de idiomas ni reiniciar VS Code para observar el cambio.

Comportamiento esperado

.svelte archivos

Sistema (complete la siguiente información):

SO: macOS 10.15.7
IDE: Código VS 1.52.1
Complemento / Paquete: "Svelte para VSCode"

Contexto adicional

Como se discutió con @dummdidumm en Svelte Discord en #language-tools . A la atención de @ jasonlyu123.

De @dummdidumm en Discord:

dummdidumm: Sí, los tokens semánticos pueden ser lentos en archivos grandes, especialmente porque necesitamos hacer muchas asignaciones de mapas de origen
dummdidumm: @ jasonlyu09 tal vez deberíamos agregar algunos límites para archivos / rangos grandes, esencialmente no hacer la solicitud si el rango solicitado para analizar se vuelve demasiado grande. Creo que VS Code hace algo similar.

Fixed bug

Fuente

shirakaba

Todos 4 comentarios

Sí, la extensión mecanografiada de VSCode lo limitó a 100000. Pero me pareció muy lento para nosotros, tal vez debido al mapeo de la fuente, creo que lo limitaría a 50000;

jasonlyu123 en 19 ene. 2021

Sí, la extensión mecanografiada de VSCode lo limitó a 100000. Pero me pareció muy lento para nosotros, tal vez debido al mapeo de la fuente, creo que lo limitaría a 50000;

@ jasonlyu123 ¿ 100.000 de qué? Mi archivo de 2600 líneas tiene 128,292 caracteres, por lo que si se supone que debe deshabilitar los tokens semánticos para archivos con más de 100,000 caracteres, no pareció hacerlo en absoluto.

Aunque si se trata de la longitud de algún archivo generado (su RP menciona TSX, así que tal vez lo sea), en lugar de la fuente en sí, no sé qué longitud tienen mis archivos generados.

shirakaba en 19 ene. 2021

Caracteres, si el archivo js / ts excede ese carácter, la extensión mecanografiada no procesará los tokens semánticos del archivo completo. Probé el número en la extensión esbelta en modo de depuración y todavía parece ser demasiado lento.

Hay varios tipos de solicitudes de tokens semánticos que el servidor de idiomas puede implementar. Actualmente implementamos una extensión de mecanografiado similar a un rango y un archivo completo. Según tengo entendido, parece que vscode intentará obtener los resultados de rango solo cuando el archivo completo no esté disponible. Y el rango uno es el motivo por el que verá un cambio de color repentino al desplazarse hacia abajo en el documento.

jasonlyu123 en 19 ene. 2021

👍1

Ahora tiene un tope. Veamos ahora si se puede volver a utilizar al activar los tokens semánticos.