Language-tools: Starke Speicherauslastung des Sprachservers

Der Sprachserver verwendet im Hintergrund den Sprachdienst von typescript. Ich vermute, der hohe Speicher liegt daran, dass Typoskript versucht, alle konfigurierten Dateien in jsconfig.json zu analysieren, um eingeschlossen zu werden. Da sich der Typescript-Sprachdienst im selben Prozess wie der schlanke Sprachserver befindet, weiß ich nicht, wie viel Speicher der Typescript-Sprachdienst verwendet.

Ich bin gespannt, wie groß Ihr __sapper__ Ordner ist. Mein Projekt hat ein jsconfig.json und ist so eingestellt, dass es etwa 200 js-Quelldateien enthält und nur 150 MB verwendet. Ich kann mir nicht vorstellen, wie Ihr __sapper__ Ordner dazu führt, dass der Sprachserver mehr als 2 GB Speicher verwendet.

Als Referenz hier das Repo meines Projekts: b339c2a17e @ Innopoints/frontend

Ich habe es frisch geklont und den Server ausgeführt und Folgendes erhalten:

• 490 MB, wenn der Ordner __sapper__ den Entwickler-Build enthält
• 730 MB, wenn der Ordner __sapper__ die Entwicklungs- und Produktions-Builds enthält

Sie können versuchen, es selbst zu kompilieren, um dies zu reproduzieren (beachten Sie, dass der Dev-Server nicht ohne Umgebungsvariablen läuft, aber das ist in Ordnung, da die Kompilierung sowieso erfolgreich ist). Installieren Sie deps mit Yarn, kompilieren Sie mit yarn dev und öffnen Sie dann eine beliebige .svelte Datei in VS Code.

Wenn es überhaupt einen Unterschied macht, verwende ich VSCodium im Gegensatz zum regulären VS-Code

Gibt es eine Möglichkeit, SLS so einzustellen, dass nur .svelte Dateien gescannt werden? Ich glaube nicht, dass .js/.ts Dateien wirklich relevant für die Svelte-Codeanalyse sind. Vor allem diejenigen, die nicht direkt importiert werden, wie der Ordner __sapper__ .

Wenn nicht, bin ich neugierig, wie sich SLS in Abwesenheit von jsconfig.json verhält. Wie ich bereits erwähnt habe, bringt das Entfernen dieser Datei den Speicherverbrauch auf angemessene 150 MB zurück. Und es ist definitiv eine Erwähnung in der README wert, denn für mich, die Person, die mit den TS-Methoden nicht genau vertraut ist, war es eine sehr große Überraschung, dass eine scheinbar völlig unabhängige Datei jsconfig.json einen so dramatischen Unterschied verursacht.

Ja, wir sollten der Dokumentation darüber etwas hinzufügen.

Der Scan von .ts / .js Dateien ist erforderlich, um Ihnen Intellisense von svelte zu diesen Dateien zur Verfügung zu stellen. Sie würden keine Autovervollständigung/Zur Definition/Hover-Info dieser erhalten, wenn sie nicht enthalten wären.

Es fühlt sich einfach so an, als ob der Ordner __sapper__ für IntelliSense nicht von großem Nutzen ist, also kann diese Ignorierung vielleicht sogar standardmäßig eingestellt und bei Bedarf überschrieben werden

Ich erhalte immer noch Speichernutzungen von bis zu 2 GB, aber es ist sehr schwer zu verfolgen. Es fühlt sich an, als würde es zu zufälligen Zeiten explodieren, während ich die Svelte-Quelle in diesem Projekt bearbeite. Was könnten Sie empfehlen, um den Speicherverbrauch zu senken?

Der Sprachserver erkennt schlanke Dateien und durchläuft den Dateibaum davon. Es wird auch Sachen in der jsconfig/tsconfig. Aus Ihrer Erfahrung ("explodiert", nicht "steigt ständig"), vermute ich im Moment, dass der Server irgendwie an den Punkt gelangt, an dem er eine Reihe von nicht zusammenhängenden Dateien lädt, die er nicht sollte.
Sie können in VSCodes Output-> Svelte nachsehen, ob etwas verdächtig ist (oder einfach hier kopieren).

Es verhält sich heute für mich, aber gestern musste ich die Prozesse der schlanken Sprachtools nach dem Schließen von VS Code manuell beenden (reagierte nicht auf SIGTERM).

Ich habe derzeit nicht viel hinzuzufügen.

Wie groß ist Ihr Projekt? Hast du ein tsconfig.json oder jsconfig.json ?

@dummdidumm Nicht viel größer als eine Sapper-Vorlage. Ich habe eine grundlegende tsconfig.json, die sich seit dem Auftreten des Problems nicht geändert hat.

{
  "include": [
    "src/**/*"
  ],
  "exclude": [
    "node_modules/*"
  ],
  "compilerOptions": {
    "target": "es2015",
    "module": "es2015",
    "types": [
      "svelte"
    ]
  }
}

Sowohl Sie als auch @illright verwenden also Sapper und haben eine hohe Speicherauslastung. Vielleicht muss ein Muster das untersuchen.

@dummdidumm Lassen Sie mich wissen, ob ich in irgendeiner Weise bei der Untersuchung helfen kann. Vielleicht gibt es eine Möglichkeit, den SLS über die Befehlszeile auszuführen oder etwas anderes, das besser reproduzierbar ist, als nur im Editor herumzufummeln?

Svelte (Svelte Language Server) stderr FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
Svelte (Svelte Language Server) stderr  1: 0x55d7276c33b6 node::Abort() [/usr/lib/electron5/electron]
Svelte (Svelte Language Server) stderr  2: 0x55d7276c3985  [/usr/lib/electron5/electron]
Svelte (Svelte Language Server) stderr  3: 0x55d723b01817  [/usr/lib/electron5/electron]
Svelte (Svelte Language Server) stderr  4: 0x55d723b017b4  [/usr/lib/electron5/electron]
Svelte (Svelte Language Server) stderr  5: 0x55d723b6f716  [/usr/lib/electron5/electron]
Svelte (Svelte Language Server) stderr  6: 0x55d723b6e538  [/usr/lib/electron5/electron]
Svelte (Svelte Language Server) stderr  7: 0x55d723b6b626 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/usr/lib/electron5/electron]
Svelte (Svelte Language Server) stderr  8: 0x55d723b7678e  [/usr/lib/electron5/electron]
Svelte (Svelte Language Server) stderr  9: 0x55d723f210b7 v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationSpace) [/usr/lib/electron5/electron]
Svelte (Svelte Language Server) stderr 10: 0x55d72410e1be  [/usr/lib/electron5/electron]
Svelte (Svelte Language Server) stderr 11: 0x55d72440b62b  [/usr/lib/electron5/electron]
Svelte (Svelte Language Server) rpc.onClose The RPC connection closed unexpectedly

Gerade jetzt habe ich wieder 2,1 GB erreicht und den SLS SIGKILLed. Das obige war in DevTools von Atom zu sehen

Oh warte, du verwendest Atom? Welche Erweiterung verwendest du?

@dummdidumm Ich habe sowohl Atom (mit ide-svelte , das die Sprachserverversion manuell anstößt) als auch VSCodium (mit Svelte Beta).

Hier ist die Ausgabe des Svelte-Tabs von VSCodium, als die Explosion passierte. Es scheint ihn abgetötet und erholt zu haben, aber der Frost war immer noch da.

Ok ich verstehe, danke.

Scheint, als ob die Explosion sehr kurz nach dem Start passiert ist.

Wenn du mit der Erweiterung vor Ort selbst ein wenig recherchieren würdest, wäre das super! Um die Erweiterung lokal für VSCode(ium, sollte hoffentlich gleich sein) einzurichten, deinstallieren Sie sie zuerst und richten Sie sie dann lokal ein, wie hier beschrieben . Worauf Sie sich konzentrieren möchten, ist der Service . Ich vermute, dass es irgendwann zu viele Dateien bekommt, mit denen es umgehen sollte, was hier zu sehen setInterval(() => console.log(JSON.stringify(Array.from(new Set([...files, ...snapshotManager.getFileNames(), ...svelteTsxFiles]), null , 3)), 10000) ), könnte dies hilfreich sein, um einige Erkenntnisse zu gewinnen.

Es scheint also, dass snapshotManager.getFileNames() eine Reihe von Dateien enthält, die gemäß jsconfig.json nicht überwacht werden sollen. Es reagiert auch auf Dateiänderungen, indem es nichts von Sapper lädt, bis ein Build stattfindet, aber von da an füllen die __sapper__/**/*.js Dateien den Speicher aus

Okay, ich denke das ist die Ursache des Problems. Es erklärt die plötzliche Explosion, weil alle neuen Dateien zur Tracking-Liste hinzugefügt wurden.

Ja, das ist es wahrscheinlich. Ich denke, wir müssen anpassen, wie TypescriptPlugin mit ts/js-onWatchedFilesChange umgeht. Vielleicht machen Sie es wie vetur und löschen Sie nur alte Sachen, keine neuen hinzufügen. Oder fügen Sie einige Pfade für beste Schätzungen wie __sapper__ / node_modules / dist , die ignoriert werden sollten.

Ich werde versuchen, dies zu tun.

Eine schreckliche Problemumgehung, bis dieses Problem behoben ist: Suchen Sie Ihr Svelte-Erweiterungsverzeichnis, öffnen Sie node_modules/svelte-language-server/dist/src/plugins/typescript/service.js und kommentieren Sie das snapshotManager.getFileNames() :

Zeile 69:

// before:
return Array.from(new Set(__spreadArrays(files, snapshotManager.getFileNames(), svelteTsxFiles)));

// after:
return Array.from(new Set(__spreadArrays(files/*, snapshotManager.getFileNames() */, svelteTsxFiles)));

Sie verlieren etwas IntelliSense, behalten aber die Syntaxhervorhebung und zumindest die Leistung sinkt nicht zufällig. Und wenn du so etwas wie ich bist, sollte das gut genug sein, um durchzukommen :)

Ergänzend, was @illright gesagt hat. es befindet sich normalerweise in ~/.vscode/extensions oder %userprofile%\.vscode \extensions\ in Windows.

Eine andere Problemumgehung besteht darin, zu node_modules/svelte-language-server/dist/src/plugins/typescript/TypeScriptPlugin.js
Fügen Sie die folgenden Zeilen zu Zeile 237 hinzu, wo onWatchFileChanges beginnen

        if (/node_modules|__sapper__|dist/.test(fileName)) {
            return;
        }

diese Methode ist die Quelle des Problems

Ich habe eine PR #165 erstellt. Könnten Sie es im Debug versuchen und sehen, ob es sich verbessert hat?

@jasonyu123 Ja, ich

Hinweis: unter Kontrolle gehalten = ~480 MB in der Spitze. Dies ist niedrig genug, um mein System nicht zu beeinträchtigen, aber Sie könnten diesen hohen Speicherverbrauch immer noch annehmen. Ich habe 8 GB RAM auf meinem Rechner.

Der Schmerz ist echt

Selbst wenn wir standardmäßig __sapper__ , empfehle ich dennoch, __sapper__ in den Ausschluss von tsconfig.json/jsconfig.json zu setzen. Weil wir unser eigenes Typoskript-Paket verwenden. der von vscode verwendete tsserver könnte es immer noch enthalten.

@illright könnten Sie die neueste Plugin-Version überprüfen? Sollte jetzt besser sein.

VS Code wirkt wie gewohnt flüssig, ca. 400 MB Speicher belegt. Besteht die Möglichkeit, dass das Update auf SLS auf die Atom-Erweiterung übertragen wird? Das ist der Ort, an dem ich neulich einen Leistungsabfall bemerkt habe

@orta ist gerade dabei, das Atom-Plugin in dieses Repo zu übertragen. Danach sollten Sie die Updates des Sprachservers erhalten.

@rob-balfre ist die Speichernutzung bei dir auch gesunken? Wenn nicht, könnten Sie Ihr Setup spezifizieren?

Ich hatte die gleichen Probleme, das Hinzufügen von transpileOnly zum Typoskript-Präprozessor scheint die Situation erheblich zu verbessern.
In Ihrer svelte.config.js
```
const sveltePreprocess = require("svelte-preprocess");

module.exports = {
preprocess: sveltePreprocess({
Typoskript: {
transpileOnly: wahr,-
},
}),
// ...andere schlanke Optionen (optional)
};

Dies ist mir auch kurz nach der Aktualisierung von VSCode aufgefallen. Kleine Projekte scheinen kein so großes Problem zu sein (obwohl das Speichern immer noch etwas länger dauert als üblich). Das Speichern bleibt hängen, dann wird die Datei gespeichert und formatiert. Danach scheint es gut zu sein. Und das nur für kleine Projekte. Es ist, als ob es versucht, den Projektordner oder so zu indizieren und sich aufhängt? Größere Projekte mit mehr Dateien usw. hängen am Ende und führen zu Fehlern.

Der Speicherverbrauch/Fehler tritt bei mir beim Speichern einer Svelte-Datei auf. Es hängt und hängt nur mit dieser Meldung unten rechts:

Hier ist das Svelte-Ausgabefenster:

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0x1143fdbe5 node::Abort() [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework]
 2: 0x1143fdc54 node::Abort() [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework]
 3: 0x11010b237 v8::internal::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*) [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework]
 4: 0x11010b1d7 v8::internal::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*) [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework]
 5: 0x1101500a5 v8::internal::Heap::StartIdleIncrementalMarking(v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework]
 6: 0x110151719 v8::internal::Heap::StartIdleIncrementalMarking(v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework]
 7: 0x11014e3ec v8::internal::Heap::CreateFillerObjectAt(unsigned long, int, v8::internal::ClearRecordedSlots, v8::internal::ClearFreedMemoryMode) [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework]
 8: 0x11014c002 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework]
 9: 0x11015746a v8::internal::Heap::PromotedExternalMemorySize() [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework]
10: 0x110157851 v8::internal::Heap::PromotedExternalMemorySize() [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework]
11: 0x110358a5a v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationType, v8::internal::AllocationOrigin) [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework]
12: 0x1105e19bf v8::internal::RegExp::CompileForTesting(v8::internal::Isolate*, v8::internal::Zone*, v8::internal::RegExpCompileData*, v8::base::Flags<v8::internal::JSRegExp::Flag, int>, v8::internal::Handle<v8::internal::String>, v8::internal::Handle<v8::internal::String>, bool) [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework]
13: 0x110c23139 v8::internal::compiler::ZoneStats::ReturnZone(v8::internal::Zone*) [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework]
14: 0x110bf293d v8::internal::compiler::ZoneStats::ReturnZone(v8::internal::Zone*) [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework]

<--- Last few GCs --->
al[45813:0x7fe18e004200]    47201 ms: Mark-sweep 4095.0 (4102.8) -> 4094.4 (4103.3) MB, 2004.1 / 0.0 ms  (+ 6.4 ms in 18 steps since start of marking, biggest step 5.3 ms, walltime since start of marking 2020 ms) (average mu = 0.146, current mu = 0.005) all[45813:0x7fe18e004200]    50534 ms: Mark-sweep 4095.7 (4103.3) -> 4095.3 (4104.5) MB, 2648.3 / 0.0 ms  (+ 668.5 ms in 21 steps since start of marking, biggest step 50.7 ms, walltime since start of marking 3332 ms) (average mu = 0.063, current mu = 0.005) 

<--- JS stacktrace --->

==== JS stack trace =========================================

    0: ExitFrame [pc: 0x110c23139]
Security context: 0x287bc74e0dd1 <JSObject>
    1: keys [0x287bc74c15b1](this=0x287bcb9bfaa1 <Object map = 0x287be02c4cb9>,0x287bc68e8e29 <Object map = 0x287bcfd3aa99>)
    2: uvException(aka uvException) [0x287b27f974e1] [internal/errors.js:374] [bytecode=0x287b18cb32e9 offset=424](this=0x287bb6f004b1 <undefined>,0x287bc68e8e29 <Object map = 0x287bcfd3aa99>)
    3: handleErrorFromBinding(aka handleError...

[Info  - 9:59:17 PM] Connection to server got closed. Server will restart.
[Error - 9:59:17 PM] Request textDocument/formatting failed.
Error: Connection got disposed.
    at Object.dispose (/Users/babycourageous/.vscode/extensions/svelte.svelte-vscode-99.0.44/node_modules/vscode-jsonrpc/lib/main.js:904:25)
    at Object.dispose (/Users/babycourageous/.vscode/extensions/svelte.svelte-vscode-99.0.44/node_modules/vscode-languageclient/lib/client.js:74:35)
    at LanguageClient.handleConnectionClosed (/Users/babycourageous/.vscode/extensions/svelte.svelte-vscode-99.0.44/node_modules/vscode-languageclient/lib/client.js:2309:42)
    at LanguageClient.handleConnectionClosed (/Users/babycourageous/.vscode/extensions/svelte.svelte-vscode-99.0.44/node_modules/vscode-languageclient/lib/main.js:155:15)
    at closeHandler (/Users/babycourageous/.vscode/extensions/svelte.svelte-vscode-99.0.44/node_modules/vscode-languageclient/lib/client.js:2296:18)
    at CallbackList.invoke (/Users/babycourageous/.vscode/extensions/svelte.svelte-vscode-99.0.44/node_modules/vscode-jsonrpc/lib/events.js:62:39)
    at Emitter.fire (/Users/babycourageous/.vscode/extensions/svelte.svelte-vscode-99.0.44/node_modules/vscode-jsonrpc/lib/events.js:121:36)
    at closeHandler (/Users/babycourageous/.vscode/extensions/svelte.svelte-vscode-99.0.44/node_modules/vscode-jsonrpc/lib/main.js:240:26)
    at CallbackList.invoke (/Users/babycourageous/.vscode/extensions/svelte.svelte-vscode-99.0.44/node_modules/vscode-jsonrpc/lib/events.js:62:39)
    at Emitter.fire (/Users/babycourageous/.vscode/extensions/svelte.svelte-vscode-99.0.44/node_modules/vscode-jsonrpc/lib/events.js:121:36)
    at IPCMessageReader.fireClose (/Users/babycourageous/.vscode/extensions/svelte.svelte-vscode-99.0.44/node_modules/vscode-jsonrpc/lib/messageReader.js:111:27)
    at ChildProcess.<anonymous> (/Users/babycourageous/.vscode/extensions/svelte.svelte-vscode-99.0.44/node_modules/vscode-jsonrpc/lib/messageReader.js:213:45)
    at ChildProcess.emit (events.js:208:15)
    at ChildProcess.EventEmitter.emit (domain.js:476:20)
    at maybeClose (internal/child_process.js:1021:16)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:283:5)
[Error - 9:59:17 PM] Request textDocument/hover failed.
Error: Connection got disposed.
    at Object.dispose (/Users/babycourageous/.vscode/extensions/svelte.svelte-vscode-99.0.44/node_modules/vscode-jsonrpc/lib/main.js:904:25)
    at Object.dispose (/Users/babycourageous/.vscode/extensions/svelte.svelte-vscode-99.0.44/node_modules/vscode-languageclient/lib/client.js:74:35)
    at LanguageClient.handleConnectionClosed (/Users/babycourageous/.vscode/extensions/svelte.svelte-vscode-99.0.44/node_modules/vscode-languageclient/lib/client.js:2309:42)
    at LanguageClient.handleConnectionClosed (/Users/babycourageous/.vscode/extensions/svelte.svelte-vscode-99.0.44/node_modules/vscode-languageclient/lib/main.js:155:15)
    at closeHandler (/Users/babycourageous/.vscode/extensions/svelte.svelte-vscode-99.0.44/node_modules/vscode-languageclient/lib/client.js:2296:18)
    at CallbackList.invoke (/Users/babycourageous/.vscode/extensions/svelte.svelte-vscode-99.0.44/node_modules/vscode-jsonrpc/lib/events.js:62:39)
    at Emitter.fire (/Users/babycourageous/.vscode/extensions/svelte.svelte-vscode-99.0.44/node_modules/vscode-jsonrpc/lib/events.js:121:36)
    at closeHandler (/Users/babycourageous/.vscode/extensions/svelte.svelte-vscode-99.0.44/node_modules/vscode-jsonrpc/lib/main.js:240:26)
    at CallbackList.invoke (/Users/babycourageous/.vscode/extensions/svelte.svelte-vscode-99.0.44/node_modules/vscode-jsonrpc/lib/events.js:62:39)
    at Emitter.fire (/Users/babycourageous/.vscode/extensions/svelte.svelte-vscode-99.0.44/node_modules/vscode-jsonrpc/lib/events.js:121:36)
    at IPCMessageReader.fireClose (/Users/babycourageous/.vscode/extensions/svelte.svelte-vscode-99.0.44/node_modules/vscode-jsonrpc/lib/messageReader.js:111:27)
    at ChildProcess.<anonymous> (/Users/babycourageous/.vscode/extensions/svelte.svelte-vscode-99.0.44/node_modules/vscode-jsonrpc/lib/messageReader.js:213:45)
    at ChildProcess.emit (events.js:208:15)
    at ChildProcess.EventEmitter.emit (domain.js:476:20)
    at maybeClose (internal/child_process.js:1021:16)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:283:5)
Initialize language server at  Code/Project
Trying to load config for Code/Project/src/App.svelte
Initialize new ts service at  

Dies geschieht auch in diesem größeren Svelte-Projekt, das andere Dateien (.js usw.) speichert. Wenn ich Svelte Beta deaktiviere, ist alles in Ordnung (außer jetzt werden Svelte-Dateien nicht erkannt.

Ich wollte kein neues Problem starten, da es damit zu tun zu haben scheint, aber absolut kann, wenn dies nicht zusammenhängt.

Vielen Dank!

Danke für die Auskunft. Ich habe noch ein paar Fragen, um das einzugrenzen:

• Über wie viele svelte/js-Dateien sprechen wir?
• Passiert es sofort nach ein paar Sekunden/Minuten Arbeit mit dem Projekt oder erst nach einiger Zeit?
• Wenn Sie svelte.plugin.svelte.format.enable auf false (https://github.com/sveltejs/language-tools/tree/master/packages/svelte-vscode#sveltepluginsvelteformatenable), tritt der Fehler weiterhin auf? Oder ist die Ausgabe trotzdem mit Speicherfehlern übersät?
• Haben Sie ein tsconfig.json oder jsconfig.json ? Wenn nicht, was passiert, wenn Sie eine hinzufügen (kann nur eine einfache sein)?

Hallo @dummdidumm Danke für die schnelle Antwort!

Erstens - seit heute Morgen habe ich einige Sachen geöffnet, um Tests für Ihre Fragen durchzuführen ... und es scheint sich in Luft aufgelöst zu haben. Klassisch.

Hier sind einige Antworten für Sie für die Nachwelt:

Über wie viele svelte/js-Dateien sprechen wir?

• Kleine Projekte (<10 Dateien): Das kleine Fenster "Running Svelte Beta" wird für <10 Sekunden geöffnet, Datei gespeichert und formatiert
• Größere Projekte (>10 Dateien): Hier bin ich auf dieses Problem gestoßen. Dieses Fenster öffnet sich unten links und versucht es etwa 20-30 Sekunden lang. Dann kaput.

Passiert es sofort nach ein paar Sekunden/Minuten Arbeit mit dem Projekt oder erst nach einiger Zeit?
Bisher ist es sofort. Öffnen Sie ein Projekt, ändern Sie eine Datei, speichern Sie und die oben genannten Situationen treten auf. Und mir ist es erst nach dem VSCode-Update gestern (oder vorgestern) aufgefallen. Obwohl das Speichern von Svelte Beta im Allgemeinen langsamer war als die vorherige Erweiterung (ungefähr 2-4 Sekunden vor dem Formatieren und Speichern), wenn das von Nutzen ist.

Wenn Sie svelte.plugin.svelte.format.enable auf false setzen (https://github.com/sveltejs/language-tools/tree/master/packages/svelte-vscode#sveltepluginsvelteformatenable), tritt der Fehler weiterhin auf?
Ich kann es das nächste Mal versuchen, wenn ich merke, dass dies passiert. Leider, da es gerade zufällig aufgehört hat, glaube ich nicht, dass es etwas nützen wird, heheh.

Hast du eine tsconfig.json oder jsconfig.json?
Kein .tsconfig oder .jsconfig in meinen Projekten. Wenn Sie einfache Setups zum Teilen haben, könnte ich das beim nächsten Mal auch versuchen.

Also, alles in allem Hurra, dass es verschwunden ist, aber verdammt, wenn wir das Problem jetzt nicht kennen, hehe.

Klassisch

Ich habe die Frage jsconfig.json / tsconfig.json gestellt, weil wir zuvor einen ähnlichen Fehler hatten, bei dem der Sprachdienst beim Start viel zu viele Dateien lud, weil er eine andere Konfiguration weiter oben im Dateibaum fand (außerhalb von den Projektordner) und diese verwenden - obwohl das jetzt behoben sein sollte.

Ich werde einige Protokollierungen hinzufügen, um die geladene Anzahl der Dateien beim Start sowie jede Minute danach zu erhalten.

Klingt gut - ich melde mich wenn sich was ändert! Ich spiele jetzt in einem dieser >10-Dateien-Projekte herum und alles läuft immer noch reibungslos ...

Wir haben zusätzliche Maßnahmen hinzugefügt, um das anfängliche Aufblähen von Dateien zu verhindern. Wenn jemand immer noch eine hohe Speicherauslastung hat, melden Sie sich bitte hier. Sonst schließe ich das in ein paar Wochen.

@dummdidumm irgendwelche Updates zur Atom-Erweiterung?

Siehe #70 für Informationen und Fortschritte dazu.

Das Ausschließen von __sapper__ aus dem VSCode-Watcher hat die Erweiterung gestoppt, um für mich nicht mehr genügend Speicher zu haben.