Language-tools: Utilisation intensive de la mémoire du serveur de langue

Le serveur de langue utilise le service de langue de tapuscrit dans les coulisses. Je suppose que la mémoire élevée est due au fait que le typescript essaie d'analyser tous les fichiers configurés , dans le jsconfig.json , pour être inclus. Étant donné que le service de langage dactylographié est dans le même processus que le serveur de langage svelte, je ne sais pas combien de mémoire est utilisée par le service de langage dactylographié.

Je suis curieux de savoir quelle est la taille de votre dossier __sapper__ . Mon projet a un jsconfig.json et est configuré pour inclure environ 200 fichiers source js et n'utiliser que 150 Mo. Je ne peux pas imaginer comment votre dossier __sapper__ que le serveur de langue utilise plus de 2 Go de mémoire.

Pour référence, voici le repo de mon projet : b339c2a17e @ Innopoints/frontend

Je l'ai récemment cloné et exécuté le serveur et j'ai obtenu les éléments suivants :

• 490 Mo lorsque le dossier __sapper__ contient la version dev
• 730 Mo lorsque le dossier __sapper__ contient les versions de développement et de production

Vous pouvez essayer de le compiler vous-même pour essayer de reproduire cela (notez que le serveur de développement ne fonctionnera pas sans variables d'environnement, mais ce n'est pas grave, puisque la compilation réussira de toute façon). Installez deps avec Yarn, compilez avec yarn dev , puis ouvrez n'importe quel fichier .svelte dans VS Code.

De plus, si cela fait une différence, j'utilise VSCodium, par opposition au code VS standard.

Existe-t-il un moyen de faire pointer SLS pour analyser uniquement les fichiers .svelte ? Je ne pense pas que les fichiers .js/.ts soient vraiment pertinents pour l'analyse de code Svelte. Surtout ceux qui ne sont pas directement importés, comme le dossier __sapper__ .

Sinon, je suis curieux de savoir comment SLS se comporte en l'absence de jsconfig.json . Comme je l'ai mentionné, la suppression de ce fichier ramène la consommation de mémoire à 150 Mo adéquats. Et cela vaut vraiment la peine de le mentionner dans le README, car pour moi, la personne qui n'est pas intimement familière avec les méthodes TS, ce fut une très grande surprise qu'un fichier jsconfig.json apparemment sans rapport cause une différence si dramatique.

Oui, nous devrions ajouter quelque chose à la documentation à ce sujet.

L'analyse des fichiers .ts / .js est nécessaire pour vous fournir intellisense de svelte à ces fichiers. Vous n'obtiendriez pas la saisie semi-automatique/allez à la définition/au survol des informations de ces derniers, s'ils n'étaient pas inclus.

On a juste l'impression que le dossier __sapper__ n'est pas très utile pour IntelliSense, donc peut-être que cet ignorer peut même être défini par défaut et remplacé si nécessaire

Je reçois toujours des utilisations de mémoire allant jusqu'à 2 Go, mais c'est très difficile à tracer. J'ai l'impression qu'il explose à des moments aléatoires pendant que je modifie la source Svelte dans ce projet. Que pourriez-vous recommander pour réduire la consommation de mémoire ?

Le serveur de langue détecte les fichiers sveltes et parcourra l'arborescence des fichiers à partir de cela. Il honorera également les éléments du fichier jsconfig/tsconfig. D'après votre expérience ("explose", pas "augmente régulièrement"), je suppose que le serveur arrive d'une manière ou d'une autre au point où il charge un tas de fichiers sans rapport qu'il ne devrait pas.
Vous pouvez regarder dans Output-> Svelte de VSCode et voir s'il y a quelque chose de suspect (ou simplement le copier-coller ici)

Cela se comporte pour moi aujourd'hui, mais hier, j'ai dû tuer manuellement les processus d'outils de langage sveltes après la fermeture de VS Code (ne répondait pas à SIGTERM).

Je n'ai pas grand-chose à ajouter pour le moment.

Quelle est la taille de votre projet ? Avez-vous un tsconfig.json ou un jsconfig.json ?

@dummdidumm Pas beaucoup plus grand que le modèle de sapeur. J'ai un tsconfig.json de base qui n'a pas changé depuis que j'ai rencontré le problème.

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

Donc, vous et @illright utilisez le sapeur et avez une utilisation importante de la mémoire. Peut-être qu'un modèle... devra enquêter là-dessus.

@dummdidumm Faites-moi savoir si je peux aider à l'enquête de quelque manière que ce soit. Peut-être existe-t-il un moyen d'exécuter le SLS via la ligne de commande ou autre chose de plus reproductible que de simplement bidouiller dans l'éditeur ?

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

Tout à l'heure, j'ai à nouveau atteint 2,1 Go et SIGKILLed le SLS. Ce qui précède peut être vu dans DevTools d'Atom

Oh attends, tu utilises Atom ? Quelle extension utilisez-vous ?

@dummdidumm J'ai à la fois Atom (avec ide-svelte , supprimant manuellement la version du serveur de langue) et VSCodium (avec Svelte Beta).

Voici la sortie de l'onglet Svelte de VSCodium lorsque l'explosion s'est produite. Il semble l'avoir tué et récupéré, mais le gel était toujours là.

D'accord j'ai compris, merci.

On dirait que l'explosion s'est produite très peu de temps après le démarrage.

Si vous pouviez enquêter un peu vous-même avec l'extension localement, ce serait génial ! Pour configurer l'extension localement pour VSCode (ium, devrait être le même, espérons-le), désinstallez-la d'abord, puis configurez-la localement comme expliqué ici . Ce sur quoi vous voulez vous concentrer, c'est le service . Je suppose qu'à un moment donné, il reçoit trop de fichiers qu'il devrait traiter, ce qui peut être vu ici . Si vous ajoutez un journal de console ci-dessus (ligne 72) qui enregistre les fichiers (peut-être dans un intervalle de 10 secondes, comme setInterval(() => console.log(JSON.stringify(Array.from(new Set([...files, ...snapshotManager.getFileNames(), ...svelteTsxFiles]), null , 3)), 10000) ) cela pourrait aider à obtenir des informations.

Il semble donc que snapshotManager.getFileNames() contienne un tas de fichiers qui ne sont pas censés être regardés selon jsconfig.json . Il répond également au changement de fichier, en ce sens qu'il ne charge rien de Sapper jusqu'à ce qu'une construction se produise, mais à partir de là, les fichiers __sapper__/**/*.js remplissent la mémoire

Ok, je suppose que c'est la source du problème. Cela explique l'explosion soudaine car tous les nouveaux fichiers ont été ajoutés à la liste de suivi.

Oui, c'est probablement ça. Je pense que nous devons ajuster la façon dont TypescriptPlugin gère le ts/js-onWatchedFilesChange. Faites -le peut-être comme le fait __sapper__ / node_modules / dist qui devraient être ignorés.

Je vais essayer de faire ça.

Une terrible solution de contournement jusqu'à ce que ce problème soit résolu : localisez votre répertoire d'extension Svelte, ouvrez node_modules/svelte-language-server/dist/src/plugins/typescript/service.js et commentez le snapshotManager.getFileNames() :

Ligne 69 :

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

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

Vous perdez un peu d'IntelliSense, mais conservez la coloration syntaxique et au moins les performances ne baissent pas au hasard. Et si vous êtes comme moi, cela devrait suffire à vous en sortir :)

Complétant ce que @illright a dit. il est généralement situé dans ~/.vscode/extensions ou %userprofile%\.vscode \extensions\ dans Windows.

Une autre solution consiste à aller à node_modules/svelte-language-server/dist/src/plugins/typescript/TypeScriptPlugin.js
Ajoutez les lignes suivantes à la ligne 237 où onWatchFileChanges commencent

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

cette méthode est la source du problème

J'ai créé un PR #165. Pourriez-vous l'essayer dans le débogage et voir si cela s'est amélioré ?

@ jasonulu123 Oui, je constate une amélioration. Pendant un certain temps de bidouillage avec mon projet, la consommation de mémoire a été maîtrisée. Les reconstructions de Sapper semblent également ne pas déclencher de débordements de mémoire.

Remarque : gardé sous contrôle = ~480 Mo au maximum. C'est suffisamment bas pour ne pas affecter mon système, mais vous pouvez toujours considérer cette consommation de mémoire élevée. J'ai 8 Go de RAM sur ma machine.

La douleur est réelle

Même si nous excluons par défaut __sapper__ , je recommanderai toujours de mettre __sapper__ dans l'exclusion de votre tsconfig.json/jsconfig.json. Parce que nous utilisons notre propre paquet de scripts dactylographiés. le tsserver utilisé par vscode peut toujours l'inclure.

@illright pourriez-vous vérifier avec la dernière version du plugin ? Ça devrait aller mieux maintenant.

VS Code semble fluide comme d'habitude, environ 400 Mo de mémoire utilisés. Une chance que la mise à jour vers SLS puisse être poussée vers l'extension Atom ? C'est l'endroit où j'ai remarqué des baisses de performances l'autre jour

@orta est en train de transférer le plugin Atom dans ce référentiel. Après cela, vous devriez obtenir les mises à jour du serveur de langue.

@rob-balfre l'utilisation de la mémoire a-t-elle également diminué pour vous ? Si non, pouvez-vous préciser votre configuration ?

Je rencontrais les mêmes problèmes, l'ajout de transpileOnly au préprocesseur dactylographié semble améliorer considérablement la situation.
Dans votre svelte.config.js
```
const sveltePreprocess = require("svelte-preprocess");

module.exports = {
prétraitement : sveltePreprocess({
dactylographié : {
transpileOnly : vrai,
},
}),
// ...autres options sveltes (facultatif)
} ;

J'ai également remarqué cela peu de temps après la mise à jour récente de VSCode. Les petits projets ne semblent pas être un problème aussi important (bien que l'enregistrement prenne encore un peu plus de temps que d'habitude). L'enregistrement se bloquera, puis le fichier sera enregistré et formaté. Après ça a l'air bien. Et c'est pour les petits projets seulement. C'est comme s'il essayait d'indexer le dossier du projet ou quelque chose et qu'il raccrochait ? Les projets plus volumineux avec plus de fichiers, etc. finissent par se bloquer et se tromper.

L'utilisation/l'erreur de mémoire pour moi se produit lors de l'enregistrement d'un fichier Svelte. Il se bloque et se bloque avec ce message en bas à droite :

Voici la fenêtre de sortie Svelte :

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  

Cela se produit également dans ce projet Svelte plus important en enregistrant d'autres fichiers (.js, etc.). Si je désactive Svelte Beta, tout va bien (sauf que maintenant les fichiers Svelte ne sont pas reconnus.

Je ne voulais pas commencer un nouveau problème car il semble lié à cela, mais je le peux absolument si ce n'est pas lié.

Merci!

Merci pour l'information. J'ai d'autres questions pour affiner ceci :

• De combien de fichiers svelte/js parlons-nous ?
• Est-ce que cela se produit tout de suite après quelques secondes/minutes de travail avec le projet ou seulement après un certain temps ?
• Si vous définissez svelte.plugin.svelte.format.enable sur false (https://github.com/sveltejs/language-tools/tree/master/packages/svelte-vscode#sveltepluginsvelteformatenable), l'erreur se produit-elle toujours ? Ou la sortie est-elle jonchée d'erreurs de mémoire malgré tout ?
• Avez-vous un tsconfig.json ou un jsconfig.json ? Si vous ne le faites pas, que se passe-t-il si vous en ajoutez un (cela peut être simple) ?

Salut @dummdidumm Merci pour la réponse rapide !

Tout d'abord - depuis ce matin, j'ai ouvert des trucs pour faire des tests pour vos questions... et il semble s'être évanoui dans les airs. Classique.

Voici quelques réponses pour vous pour la postérité :

De combien de fichiers svelte/js parlons-nous ?

• Petits projets (<10 fichiers) : La petite fenêtre "Running Svelte Beta" s'affiche pendant <10 secondes, sauvegarde et formatage des fichiers
• Projets plus volumineux (> 10 fichiers) : c'est là que j'ai rencontré ce problème. Cette fenêtre apparaît en bas à gauche et essaie pendant environ 20 à 30 secondes. Alors kaput.

Est-ce que cela se produit tout de suite après quelques secondes/minutes de travail avec le projet ou seulement après un certain temps ?
Pour l'instant c'est tout de suite. Ouvrez un projet, modifiez un fichier, enregistrez et des situations ci-dessus se produisent. Et je ne l'ai remarqué qu'après la mise à jour de VSCode hier (ou la veille). Bien que Svelte Beta ait été plus lent à enregistrer en général que l'extension précédente (environ 2 à 4 secondes avant le formatage et l'enregistrement), si cela est utile.

Si vous définissez svelte.plugin.svelte.format.enable sur false (https://github.com/sveltejs/language-tools/tree/master/packages/svelte-vscode#sveltepluginsvelteformatenable), l'erreur se produit-elle toujours ?
Je peux essayer ceci la prochaine fois que je constate que cela se produit. Malheureusement, comme il s'est arrêté au hasard tout à l'heure, je ne pense pas que cela fera du bien, heheh.

Avez-vous un tsconfig.json ou jsconfig.json ?
Non .tsconfig ou .jsconfig dans aucun de mes projets. Si vous avez des configurations simples à partager, je pourrais également les essayer la prochaine fois.

Donc, dans l'ensemble hourra qu'il a disparu, mais bon sang si nous ne connaissons pas le problème maintenant, hehe.

Classique 😄

J'ai posé la question jsconfig.json / tsconfig.json car nous avions déjà eu une erreur similaire où le service de langue chargeait beaucoup trop de fichiers au démarrage car il trouvait une autre configuration plus haut dans l'arborescence des fichiers (en dehors de le dossier du projet) et en l'utilisant - bien que cela devrait être corrigé maintenant.

J'ajouterai une journalisation pour obtenir le nombre de fichiers chargés au démarrage ainsi que toutes les minutes par la suite.

Ça a l'air bien - je vous ferai savoir si quelque chose change ! Je joue maintenant dans l'un de ces projets de >10 fichiers et tout se passe toujours bien...

Nous avons ajouté des mesures supplémentaires pour éviter le gonflement du fichier initial. Si quelqu'un éprouve encore une utilisation élevée de la mémoire, veuillez le signaler ici. Sinon je fermerai ça dans quelques semaines.

@dummdidumm des mises à jour sur l'extension Atom ?

Voir #70 pour des informations et des progrès à ce sujet.

L'exclusion de __sapper__ de VSCode watcher a arrêté l'extension pour manquer de mémoire pour moi.