Language-tools: L'activation de la fonctionnalité des jetons sémantiques sur les fichiers volumineux entraîne une lenteur inutilisable du serveur de langue

Créé le 18 janv. 2021 · 4Commentaires · Source: sveltejs/language-tools

Décrivez le bogue

Le plugin VS Code Svelte v104.0.0 a introduit la prise en charge des jetons sémantiques. Par défaut, ceci est activé :

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

... Cependant, cela entraîne un ralentissement important des fichiers .svelte où un élément <script lang="ts"> consiste en une grande quantité de TypeScript (dans mon cas, 2 600 lignes). Le serveur de langue ne répond plus, la vérification du type prenant plus d'une minute et les infobulles se figent indéfiniment sur "Chargement...".

Reproduire

Avec le plugin VS Code Svelte v104.0.0 installé et l'option par défaut de "svelte.plugin.typescript.semanticTokens.enable": true appliquée, créez un fichier .svelte avec, disons, 2 600 lignes de code TypeScript. Créez délibérément une erreur de compilation et observez que toute vérification de type prend beaucoup de temps pour répondre.

Vous pouvez mettre à jour les paramètres à "svelte.plugin.typescript.semanticTokens.enable": false et le voir redevenir instantanément réactif. Pas besoin de redémarrer le serveur de langue, ni de redémarrer VS Code, pour observer le changement.

Comportement prévisible

.svelte fichiers

Système (veuillez compléter les informations suivantes) :

Système d'exploitation : macOS 10.15.7
IDE : VS Code 1.52.1
Plugin/Package : "Svelte pour VSCode"

Contexte supplémentaire

Comme discuté avec @dummdidumm sur le Svelte Discord dans #language-tools . A l'attention de @jasonulu123.

De @dummdidumm sur Discord :

dummdidumm : Ouais, les jetons sémantiques peuvent être lents sur les gros fichiers, d'autant plus que nous devons faire de nombreux mappages de sources
dummdidumm: @ jasonyu09 nous devrions peut-être ajouter des limites pour les fichiers/plages volumineux, essentiellement en ne faisant pas la demande si la plage demandée à analyser devient trop grande. Je pense que VS Code fait quelque chose de similaire.

Fixed bug

Source

shirakaba

Tous les 4 commentaires

Oui, l'extension dactylographiée de VSCode l'a plafonné à 100 000. Mais je l'ai trouvé encore très lent pour nous, peut-être à cause du mappage de la source, je pense que je le limiterais à 50 000 ;

jasonlyu123 le 19 janv. 2021

Oui, l'extension dactylographiée de VSCode l'a plafonné à 100 000. Mais je l'ai trouvé encore très lent pour nous, peut-être à cause du mappage de la source, je pense que je le limiterais à 50 000 ;

@jasonulu123 100 000 de quoi ? Mon fichier de 2 600 lignes contient 128 292 caractères, donc s'il est censé désactiver les jetons sémantiques pour les fichiers de plus de 100 000 caractères, cela ne semble pas du tout le faire.

Bien que s'il s'agisse de la longueur d'un fichier généré (votre PR mentionne TSX, alors c'est peut-être le cas), plutôt que de la source elle-même, je ne sais pas quelle est la longueur de mes fichiers générés.

shirakaba le 19 janv. 2021

Caractères, si le fichier js/ts dépasse ce caractère, l'extension dactylographiée ne traitera pas l'intégralité des jetons sémantiques du fichier. J'ai essayé le numéro sur l'extension svelte en mode débogage et il semble toujours trop lent.

Il existe plusieurs types de demandes de jetons sémantiques que le serveur de langage peut implémenter. Nous implémentons actuellement une extension de type range et full-file comme dactylographiée. D'après ce que j'ai compris, il semble que vscode essaie d'obtenir les résultats à distance uniquement lorsque le fichier complet n'est pas disponible. Et la plage un est la raison pour laquelle vous verrez un changement de couleur soudain lorsque vous faites défiler le document.

jasonlyu123 le 19 janv. 2021

👍1

C'est désormais plafonné. Voyons maintenant s'il est à nouveau utilisable lors de l'activation des jetons sémantiques.