Language-tools: Uso intensivo de memoria del servidor de idiomas

El servidor de idiomas utiliza el servicio de idiomas mecanografiado entre bastidores. Supongo que la memoria alta se debe a que el mecanografiado intenta analizar todos los archivos configurados , en el jsconfig.json , que se incluirán. Debido a que el servicio de lenguaje mecanografiado está en el mismo proceso que el servidor de lenguaje esbelto, no sé cuánta memoria utiliza el servicio de lenguaje mecanografiado.

Tengo curiosidad por saber qué tan grande es su carpeta __sapper__ . Mi proyecto tiene un jsconfig.json y está configurado para incluir alrededor de 200 archivos fuente js y solo usa 150 MB. No puedo imaginar cómo su carpeta __sapper__ hace que el servidor de idioma use más de 2GB de memoria.

Como referencia, aquí está el repositorio de mi proyecto: b339c2a17e @ Innopoints / frontend

Recién lo cloné y ejecuté el servidor y obtuve lo siguiente:

• 490 MB cuando la carpeta __sapper__ contiene la compilación de desarrollo
• 730 MB cuando la carpeta __sapper__ contiene las compilaciones de desarrollo y producción

Pueden intentar compilarlo ustedes mismos para intentar reproducir esto (tenga en cuenta que el servidor de desarrollo no se ejecutará sin variables de entorno, pero está bien, ya que la compilación se realizará correctamente de todos modos). Instale deps con Yarn, compile con yarn dev y luego abra cualquier archivo .svelte en VS Code.

Además, si hace alguna diferencia, estoy usando VSCodium, a diferencia del código VS normal

¿Hay alguna forma de apuntar a SLS para que solo escanee archivos .svelte ? No creo que los archivos .js/.ts sean realmente relevantes para el análisis de código de Svelte. Especialmente los que no se importan directamente, como la carpeta __sapper__ .

Si no, tengo curiosidad por saber cómo se comporta SLS en ausencia de jsconfig.json . Como mencioné, eliminar ese archivo devuelve el consumo de memoria a 150 MB adecuados. Y definitivamente vale la pena mencionarlo en el README, porque para mí, la persona que no está íntimamente familiarizada con las formas de TS, fue una gran sorpresa que un archivo jsconfig.json aparentemente sin relación alguna esté causando una diferencia tan dramática.

Sí, deberíamos agregar algo a la documentación sobre eso.

El escaneo de .ts / .js archivos es necesario para proporcionarle intellisense desde esbelto hasta estos archivos. No obtendría autocompletar / ir a la definición / información flotante de estos, si no estuvieran incluidos.

Simplemente parece que la carpeta __sapper__ no es de mucha utilidad para IntelliSense, por lo que tal vez este ignorar se pueda configurar de forma predeterminada y anular si es necesario

Todavía obtengo usos de memoria de hasta 2 GB, pero es muy difícil de rastrear. Parece que explota en momentos aleatorios mientras edito la fuente de Svelte en ese proyecto. ¿Qué recomendarías para reducir el consumo de memoria?

El servidor de idiomas detecta archivos esbeltos y recorre el árbol de archivos desde allí. También honrará cosas en jsconfig / tsconfig. Según su experiencia ("explota", no "aumenta constantemente"), mi conjetura en este momento es que de alguna manera el servidor llega al punto en el que carga un montón de archivos no relacionados que no debería.
Puede buscar en la Salida de VSCode-> Svelte y ver si hay algo sospechoso (o simplemente copiarlo aquí)

Se está comportando para mí hoy, pero ayer tuve que eliminar manualmente los procesos de herramientas de lenguaje esbeltas después de cerrar VS Code (no respondía a SIGTERM).

No tengo mucho más que agregar en este momento.

¿Qué tan grande es tu proyecto? ¿Tiene un tsconfig.json o jsconfig.json ?

@dummdidumm No es mucho más grande que la plantilla de zapador. Tengo un tsconfig.json básico que no ha cambiado desde que encontré el problema.

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

Entonces, tanto usted como @illright usan zapador y tienen un uso

@dummdidumm Avíseme si puedo ayudar con la investigación de alguna manera. ¿Quizás hay una manera de ejecutar el SLS a través de la línea de comandos o algo más reproducible que simplemente jugar en el editor?

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

Justo ahora volví a alcanzar los 2.1GB y SIGKILLed el SLS. Lo anterior se puede ver en DevTools of Atom

Oh, espera, ¿estás usando Atom? ¿Qué extensión estás usando?

@dummdidumm Tengo Atom (con ide-svelte , cargando manualmente la versión del servidor de idioma) y VSCodium (con Svelte Beta).

Aquí está la salida de la pestaña Svelte de VSCodium cuando ocurrió la explosión. Parece que lo mató y se recuperó, pero la congelación todavía estaba allí.

Ok, lo entiendo, gracias.

Parece que la explosión ocurrió poco después del inicio.

Si pudieras investigar un poco tú mismo con la extensión localmente, ¡sería genial! Para configurar la extensión localmente para VSCode (ium, debería ser el mismo con suerte), primero desinstálelo y luego configúrelo localmente como se explica aquí . En lo que quieres concentrarte es en el servicio . Supongo que en algún momento obtiene demasiados archivos con los que debería tratar, que se pueden ver aquí . Si agrega un registro de consola arriba (línea 72) que registra los archivos (tal vez en un intervalo de 10 segundos, como setInterval(() => console.log(JSON.stringify(Array.from(new Set([...files, ...snapshotManager.getFileNames(), ...svelteTsxFiles]), null , 3)), 10000) ) eso podría ayudar a obtener algunas ideas.

Por lo tanto, parece que snapshotManager.getFileNames() contiene un montón de archivos que se supone que no se deben ver de acuerdo con jsconfig.json . También responde al cambio de archivo, ya que no carga nada de Sapper hasta que ocurre una compilación, pero a partir de ese momento, los archivos __sapper__/**/*.js llenan la memoria

Ok, supongo que esa es la fuente del problema. Explica la explosión repentina porque todos los archivos nuevos se agregaron a la lista de seguimiento.

Sí, probablemente sea eso. Creo que debemos ajustar la forma en que TypescriptPlugin maneja ts / js-onWatchedFilesChange. Tal vez hacerlo como vetur es y solo eliminar cosas viejas, no agregar nuevas. O agregue algunas rutas de mejor conjetura como __sapper__ / node_modules / dist que deben ignorarse.

Intentaré hacer esto.

Una solución terrible hasta que se solucione este problema: ubique su directorio de extensión Svelte, abra node_modules/svelte-language-server/dist/src/plugins/typescript/service.js y comente el snapshotManager.getFileNames() :

Línea 69:

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

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

Pierde algo de IntelliSense, pero conserva el resaltado de sintaxis y al menos el rendimiento no cae al azar. Y si eres como yo, eso debería ser lo suficientemente bueno para sobrevivir :)

Complementando lo que dijo @illright . generalmente se encuentra en ~/.vscode/extensions o %userprofile%\.vscode \extensions\ en Windows.

Otra solución alternativa es ir a node_modules/svelte-language-server/dist/src/plugins/typescript/TypeScriptPlugin.js
Agregue las siguientes líneas a la línea 237 donde onWatchFileChanges start

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

este método es la fuente del problema

Creé un PR # 165. ¿Podrían probarlo en depuración y ver si mejora?

@ jasonlyu123 Sí, noto una mejora. Durante un tiempo jugando con mi proyecto, el consumo de memoria se mantuvo bajo control. Las reconstrucciones de zapadores tampoco parecen desencadenar desbordamientos de memoria.

Nota: mantenido bajo control = ~ 480 MB en el pico. Esto es lo suficientemente bajo como para no afectar mi sistema, pero aún puede considerar este alto consumo de memoria. Tengo 8 GB de RAM en mi máquina.

El dolor es real 😭

Incluso si por defecto excluimos __sapper__ , todavía recomendaré poner __sapper__ en la exclusión de su tsconfig.json / jsconfig.json. Porque estamos usando nuestro propio paquete de mecanografiado. el tsserver usado por vscode aún podría incluirlo.

@illright, ¿ podrías consultar con la última versión del complemento? Debería estar mejor ahora.

VS Code parece fluido como de costumbre, se utilizan unos 400 MB de memoria. ¿Existe la posibilidad de que la actualización de SLS se pueda enviar a la extensión Atom? Ese es el lugar donde he notado que el rendimiento cae el otro día.

@orta está transfiriendo el complemento Atom a este repositorio. Una vez hecho esto, debería obtener las actualizaciones del servidor de idiomas.

@ rob-balfre, ¿el uso de memoria también se redujo para usted? Si no es así, ¿podría especificar su configuración?

Estaba experimentando los mismos problemas, agregar transpileOnly al preprocesador de mecanografiado parece mejorar enormemente la situación.
En su svelte.config.js
''
const sveltePreprocess = require ("svelte-preprocess");

module.exports = {
preproceso: sveltePreprocess ({
mecanografiado: {
transpileOnly: verdadero,
},
}),
// ... otras opciones esbeltas (opcional)
};

También noté esto poco después de actualizar VSCode recientemente. Los proyectos pequeños no parecen ser un problema tan importante (aunque el ahorro todavía está tardando un poco más de lo habitual). El guardado se bloqueará, luego el archivo se guardará y formateará. Después de eso, parece estar bien. Y esto es solo para proyectos pequeños. ¿Es como si estuviera tratando de indexar la carpeta del proyecto o algo así y se quedara colgado? Los proyectos más grandes con más archivos, etc., terminan colgados y con errores.

El uso de memoria / error para mí ocurre al guardar un archivo Svelte. Simplemente cuelga y cuelga con este mensaje en la parte inferior derecha:

Aquí está la ventana de salida de 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  

Esto también sucede en este proyecto más grande de Svelte que guarda otros archivos (.js, etc.). Si desactivo Svelte Beta, todo está bien (excepto que ahora los archivos Svelte no se reconocen.

No quería iniciar un nuevo problema ya que parece estar relacionado con esto, pero absolutamente puedo si esto no está relacionado.

¡Gracias!

Gracias por la información. Tengo algunas preguntas más para reducir esto:

• ¿De cuántos archivos svelte / js estamos hablando?
• ¿Ocurre inmediatamente después de unos segundos / minutos trabajando con el proyecto o solo después de un tiempo?
• Si configura svelte.plugin.svelte.format.enable en false (https://github.com/sveltejs/language-tools/tree/master/packages/svelte-vscode#sveltepluginsvelteformatenable), ¿se sigue produciendo el error? ¿O la salida está llena de errores de memoria independientemente?
• ¿Tiene un tsconfig.json o jsconfig.json ? Si no lo hace, ¿qué sucede si agrega uno (puede ser uno simple)?

Hola @dummdidumm ¡ Gracias por la rápida respuesta!

Primero, a partir de esta mañana abrí algunas cosas para ejecutar pruebas para sus preguntas ... y parece que se ha desvanecido en el aire. Clásico.

Aquí tienes algunas respuestas para la posteridad:

¿De cuántos archivos svelte / js estamos hablando?

• Proyectos pequeños (<10 archivos): la pequeña ventana "Running Svelte Beta" aparece durante <10 segundos, el archivo se guarda y formatea
• Proyectos más grandes (> 10 archivos): aquí es donde estaba encontrando ese problema. Esa ventana aparece en la parte inferior izquierda y lo intenta y lo intenta durante unos 20-30 segundos. Entonces kaput.

¿Ocurre inmediatamente después de unos segundos / minutos trabajando con el proyecto o solo después de algún tiempo?
Hasta ahora es de inmediato. Abra un proyecto, modifique un archivo, guarde y ocurran situaciones anteriores. Y solo lo noté después de la actualización de VSCode ayer (o el día anterior). Aunque Svelte Beta fue más lento para guardar en general que la extensión anterior (aproximadamente 2-4 segundos antes de que ocurra el formateo y guardado), si eso es de alguna utilidad.

Si establece svelte.plugin.svelte.format.enable en falso (https://github.com/sveltejs/language-tools/tree/master/packages/svelte-vscode#sveltepluginsvelteformatenable), ¿se sigue produciendo el error?
Puedo intentar esto la próxima vez que note que esto está sucediendo. Desafortunadamente, dado que se detuvo al azar en este momento, no creo que sirva de nada, jeje.

¿Tiene tsconfig.json o jsconfig.json?
No .tsconfig o .jsconfig en ninguno de mis proyectos. Si tiene alguna configuración simple para compartir, podría probarla también la próxima vez.

Entonces, en general, hurra que desapareció, pero maldita sea si no sabemos el problema ahora, jeje.

Clásico 😄

Hice la pregunta jsconfig.json / tsconfig.json porque teníamos un error similar anteriormente en el que el servicio de idioma cargaba demasiados archivos al inicio porque estaba encontrando otra configuración más arriba en el árbol de archivos (fuera de la carpeta del proyecto) y usar eso, aunque eso ya debería estar arreglado.

Agregaré algunos registros para obtener la cantidad de archivos cargados en el inicio, así como cada minuto después.

Suena bien, ¡te avisaré si algo cambia! Estoy jugando en uno de esos proyectos de> 10 archivos ahora y todo sigue funcionando sin problemas ...

Agregamos medidas adicionales para evitar la hinchazón del archivo inicial. Si alguien aún experimenta un uso elevado de memoria, infórmenos aquí. De lo contrario, cerraré esto en unas pocas semanas.

@dummdidumm ¿ alguna actualización sobre la extensión Atom?

Consulte el n. ° 70 para obtener información y avances al respecto.

La exclusión de __sapper__ del observador de VSCode detuvo la extensión para que se quedara sin memoria.