Language-tools: Das Aktivieren der Semantic Tokens-Funktion für große Dateien führt dazu, dass der Sprachserver unbrauchbar langsam wird

Erstellt am 18. Jan. 2021  ·  4Kommentare  ·  Quelle: sveltejs/language-tools

Beschreibe den Fehler

Das VS Code Svelte-Plugin v104.0.0 hat die Unterstützung für semantische Token eingeführt. Standardmäßig ist dies aktiviert:

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

... Dies führt jedoch zu einer erheblichen Verlangsamung in .svelte Dateien, bei denen ein <script lang="ts"> Element aus einer großen Menge TypeScript besteht (in meinem Fall 2.600 Zeilen). Der Sprachserver reagiert praktisch nicht mehr, die Typprüfung dauert eine Minute und die QuickInfos werden bei "Laden..." auf unbestimmte Zeit eingefroren.

Fortpflanzen

Wenn das VS Code Svelte-Plugin v104.0.0 installiert ist und die Standardoption "svelte.plugin.typescript.semanticTokens.enable": true angewendet wurde, erstellen Sie eine .svelte Datei mit beispielsweise 2.600 Zeilen TypeScript-Code. Erstellen Sie absichtlich einen Kompilierzeitfehler und beobachten Sie, wie alle Typprüfungen sehr lange brauchen, um zu reagieren.

Sie können die Einstellungen auf "svelte.plugin.typescript.semanticTokens.enable": false aktualisieren und sehen, dass es sofort wieder reagiert. Es ist nicht erforderlich, den Sprachserver oder VS Code neu zu starten, um die Änderung zu beobachten.

Erwartetes Verhalten

.svelte Dateien, die TypeScript-Skripte enthalten, sollten unabhängig von der Größe der Skripte reaktionsfähig bleiben, und es sollte keine zusätzliche Konfiguration durch den Entwickler erforderlich sein, um eine nutzbare Leistung aufrechtzuerhalten.

System (bitte füllen Sie die folgenden Informationen aus):

  • Betriebssystem: macOS 10.15.7
  • IDE: VS-Code 1.52.1
  • Plugin/Paket: "Svelte für VSCode"

Zusätzlicher Kontext

Wie mit @dummdidumm im Svelte Discord in #language-tools besprochen. Zu Händen von @jasonyu123.

Von @dummdidumm auf Discord:

dummdidumm: Ja, Semantic Tokens können bei großen Dateien langsam sein, besonders da wir viele Sourcemap-Mappings durchführen müssen
dummdidumm: @jasonlyu09 Vielleicht sollten wir einige Beschränkungen für große Dateien/Bereiche hinzufügen und die Anfrage im Wesentlichen nicht stellen, wenn der angeforderte

Fixed bug

Alle 4 Kommentare

Ja, die Typoskript-Erweiterung von VSCode hat es auf 100000 begrenzt. Aber ich fand es immer noch sehr langsam für uns, vielleicht wegen der Quellzuordnung, ich denke, ich würde es auf 50000 begrenzen;

Ja, die Typoskript-Erweiterung von VSCode hat es auf 100000 begrenzt. Aber ich fand es immer noch sehr langsam für uns, vielleicht wegen der Quellzuordnung, ich denke, ich würde es auf 50000 begrenzen;

@jasonyu123 100.000 von was? Meine 2.600-Zeilen-Datei hat 128.292 Zeichen. Wenn also Semantic Tokens für Dateien mit mehr als 100.000 Zeichen deaktiviert werden sollen, scheint dies überhaupt nicht der Fall zu sein.

Wenn es jedoch um die Länge einer generierten Datei geht (Ihr PR erwähnt TSX, vielleicht ist es das), und nicht um die Quelle selbst, weiß ich nicht, wie lang meine generierten Dateien sind.

Zeichen, wenn die js/ts-Datei dieses Zeichen überschreitet, verarbeitet die Typoskript-Erweiterung nicht die vollständigen semantischen Token der Datei. Ich habe die Nummer auf der schlanken Erweiterung im Debug-Modus ausprobiert und sie scheint immer noch zu langsam zu sein.

Es gibt mehrere Arten von semantischen Token-Anforderungen, die der Sprachserver implementieren kann. Wir implementieren derzeit eine bereichs- und volldateiähnliche Typoskripterweiterung. Nach meinem Verständnis scheint es, als würde vscode nur versuchen, die Reichweitenergebnisse zu erhalten, wenn die vollständige Datei nicht verfügbar ist. Und der Bereich eins ist der Grund, warum Sie eine plötzliche Farbänderung sehen, wenn Sie im Dokument nach unten scrollen.

Es ist jetzt gekappt. Lassen Sie uns nun wissen, ob es wieder verwendbar ist, wenn semantische Token aktiviert werden.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen