Language-tools: Uso pesado de memória do Language Server

O servidor de linguagem usa o serviço de linguagem do typescript nos bastidores. Acho que a memória alta é porque o texto digitado tenta analisar todos os arquivos configurados , em jsconfig.json , para serem incluídos. Como o serviço de linguagem datilografada está no mesmo processo que o servidor de linguagem svelte, não sei quanta memória é usada pelo serviço de linguagem datilografada.

Estou curioso para saber o tamanho da sua pasta __sapper__ . Meu projeto tem um jsconfig.json definido para incluir cerca de 200 arquivos de origem js e usar apenas 150 MB. Não consigo imaginar como sua pasta __sapper__ faz com que o servidor de idioma use mais de 2 GB de memória.

Para referência, aqui está o repositório do meu projeto:

Eu acabei de cloná-lo e executar o servidor e obtive o seguinte:

• 490 MB quando a pasta __sapper__ contém o dev build
• 730 MB quando a pasta __sapper__ contém as compilações de desenvolvimento e produção

Você pode tentar compilá-lo sozinho para tentar reproduzir isso (observe que o servidor de desenvolvimento não funcionará sem variáveis ​​de ambiente, mas tudo bem, já que a compilação será bem-sucedida de qualquer maneira). Instale o deps com o Yarn, compile com yarn dev e abra qualquer arquivo .svelte no código do VS.

Além disso, se fizer alguma diferença, estou usando o VSCodium, ao contrário do código VS normal

Existe alguma maneira de apontar o SLS para verificar apenas .svelte arquivos? Não acho que .js/.ts arquivos sejam realmente relevantes para a análise de código Svelte. Especialmente aqueles que não são importados diretamente, como a pasta __sapper__ .

Do contrário, estou curioso para saber como o SLS se comporta na ausência de jsconfig.json . Como mencionei, remover esse arquivo retorna o consumo de memória para 150 MB adequados. E definitivamente vale a pena mencionar no README, porque para mim, a pessoa que não está intimamente familiarizada com os métodos de TS, foi uma grande surpresa que um arquivo jsconfig.json aparentemente completamente não relacionado esteja causando uma diferença tão dramática.

Sim, devemos adicionar algo à documentação sobre isso.

A varredura de .ts / .js arquivos é necessária para fornecer a você o intellisense de svelte para esses arquivos. Você não obteria autocompletar / ir para a definição / informações de foco destes, se eles não estivessem incluídos.

Parece que a pasta __sapper__ não é muito útil para o IntelliSense, então talvez esse ignorar possa ser definido por padrão e substituído, se necessário

Ainda consigo utilizações de memória de até 2 GB, mas é muito difícil de rastrear. Parece que ele simplesmente explode em momentos aleatórios enquanto estou editando o código-fonte Svelte naquele projeto. O que você recomendaria para reduzir o consumo de memória?

O servidor de linguagem detecta arquivos svelte e irá percorrer a árvore de arquivos a partir deles. Ele também respeitará as coisas no jsconfig / tsconfig. Pela sua experiência ("explode", não "aumenta constantemente"), meu palpite agora é que de alguma forma o servidor chega ao ponto em que carrega um monte de arquivos não relacionados que ele não deve.
Você pode olhar para o Output-> Svelte do VSCode e ver se há algo suspeito (ou apenas copiar e colar aqui)

Está se comportando para mim hoje, mas ontem eu tive que encerrar manualmente os processos de ferramentas de linguagem svelte após fechar o VS Code (não estava respondendo ao SIGTERM).

Não tenho muito mais a acrescentar neste momento.

Qual o tamanho do seu projeto? Você tem um tsconfig.json ou jsconfig.json ?

@dummdidumm Não é muito maior que o modelo sapper. Eu tenho um tsconfig.json básico que não mudou desde que encontrei o problema.

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

Portanto, você e @illright usam o sapper e usam muito a memória. Talvez um padrão .. terá que investigar isso.

@dummdidumm Deixe-me saber se posso ajudar na investigação de alguma forma. Talvez haja uma maneira de executar o SLS por meio da linha de comando ou qualquer outra coisa mais reproduzível do que apenas mexer no 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

Acabei de bater de novo em 2.1 GB e SIGKILLi o SLS. O texto acima pode ser visto no DevTools do Atom

Oh espere, você está usando o Atom? Qual extensão você está usando?

@dummdidumm Eu tenho o Atom (com ide-svelte , alterando manualmente a versão do servidor de linguagem) e o VSCodium (com Svelte Beta).

Aqui está a saída da guia Svelte do VSCodium quando a explosão aconteceu. Parece que o matou e se recuperou, mas o congelamento ainda estava lá.

Ok, eu entendo, obrigado.

Parece que a explosão aconteceu logo após a inicialização.

Se você investigasse um pouco por si mesmo com a extensão localmente, seria ótimo! Para configurar a extensão localmente para VSCode (ium, espero que seja o mesmo), primeiro desinstale-a e depois configure-a localmente como explicado aqui . O que você quer focar é no serviço . Meu palpite é que em algum momento ele obtém muitos arquivos com os quais deveria lidar, o que pode ser visto aqui . Se você adicionar um log de console acima (linha 72) que registra os arquivos (talvez em um intervalo de 10 segundos, como setInterval(() => console.log(JSON.stringify(Array.from(new Set([...files, ...snapshotManager.getFileNames(), ...svelteTsxFiles]), null , 3)), 10000) ), isso pode ajudar a obter alguns insights.

Portanto, parece que snapshotManager.getFileNames() contém um monte de arquivos que não deveriam ser observados de acordo com jsconfig.json . Ele também responde à mudança de arquivo, na medida em que não carrega nada do Sapper até que uma compilação aconteça, mas a partir de então, os arquivos __sapper__/**/*.js enchem a memória

Ok, acho que essa é a origem do problema. Isso explica a explosão repentina porque todos os novos arquivos foram adicionados à lista de rastreamento.

Sim, provavelmente é isso. Acho que precisamos ajustar a forma como o TypescriptPlugin lida com ts / js-onWatchedFilesChange. Talvez faça como vetur faz e apenas exclua coisas antigas, não adicione novas. Ou adicione alguns caminhos de melhor suposição, como __sapper__ / node_modules / dist que devem ser ignorados.

Vou tentar fazer isso.

Uma solução terrível até que esse problema seja corrigido: localize o diretório de extensão Svelte, abra node_modules/svelte-language-server/dist/src/plugins/typescript/service.js e comente o snapshotManager.getFileNames() :

Linha 69:

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

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

Você perde um pouco do IntelliSense, mas mantém o realce da sintaxe e pelo menos o desempenho não cai aleatoriamente. E se você for como eu, isso deve ser bom o suficiente para sobreviver :)

Complementando o que @illright disse. geralmente está localizado em ~/.vscode/extensions ou %userprofile%\.vscode \extensions\ no Windows.

Outra solução alternativa é ir para node_modules/svelte-language-server/dist/src/plugins/typescript/TypeScriptPlugin.js
Adicione as seguintes linhas à linha 237, onde onWatchFileChanges start

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

este método é a fonte do problema

Criei um PR # 165. Vocês poderiam tentar no debug e ver se melhorou?

@ jasonlyu123 Sim, percebi uma melhora. Por um tempo, mexendo no meu projeto, o consumo de memória foi mantido sob controle. As recompilações do sapper também parecem não estar provocando estouros de memória.

Nota: mantido sob controle = ~ 480 MB no pico. Isso é baixo o suficiente para não afetar meu sistema, mas você ainda pode considerar este alto consumo de memória. Tenho 8 GB de RAM em minha máquina.

A dor é real 😭

Mesmo se o padrão for excluir __sapper__ , eu ainda recomendo colocar __sapper__ na exclusão de seu tsconfig.json / jsconfig.json. Porque estamos usando nosso próprio pacote de texto datilografado. o tsserver usado por vscode ainda pode incluí-lo.

@illright, você poderia verificar a versão mais recente do plugin? Deve estar melhor agora.

O VS Code parece normal, com cerca de 400 MB de memória usados. Há alguma chance de a atualização para SLS ser enviada para a extensão Atom? Esse é o lugar onde tenho notado quedas de desempenho outro dia

@orta está no meio da transferência do plugin Atom para este repositório. Depois de fazer isso, você deve obter as atualizações do servidor de idioma.

@ rob-balfre o uso de memória diminuiu para você também? Se não, você poderia especificar sua configuração?

Eu estava tendo os mesmos problemas, adicionar transpileOnly ao pré-processador de texto digitado parece melhorar muito a situação.
Em seu svelte.config.js
`` `
const sveltePreprocess = require ("svelte-preprocess");

module.exports = {
preprocess: sveltePreprocess ({
datilografado: {
transpileOnly: true,
},
}),
// ... outras opções elegantes (opcional)
};

Percebi isso logo após atualizar o VSCode recentemente. Projetos pequenos não parecem ser um problema tão grande (embora salvar ainda esteja demorando um pouco mais do que o normal). O salvamento será interrompido e o arquivo será salvo e formatado. Depois disso, parece bom. E isso é apenas para pequenos projetos. É como se estivesse tentando indexar a pasta do projeto ou algo assim e travando? Projetos maiores com mais arquivos, etc, acabam travando e falhando.

O uso / erro de memória para mim acontece ao salvar um arquivo Svelte. Ele simplesmente trava e trava com esta mensagem no canto inferior direito:

Esta é a janela Svelte Output:

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  

Isso também acontece neste projeto Svelte maior, salvando outros arquivos (.js, etc). Se eu desabilitar o Svelte Beta, está tudo bem (exceto agora os arquivos Svelte não são reconhecidos.

Eu não queria começar um novo exemplar, pois parece relacionado a isso, mas com certeza posso, se não estiver relacionado.

Obrigado!

Obrigado pela informação. Eu tenho mais algumas perguntas para restringir isso:

• De quantos arquivos svelte / js estamos falando?
• Isso acontece imediatamente após alguns segundos / minutos de trabalho com o projeto ou apenas após algum tempo?
• Se você definir svelte.plugin.svelte.format.enable como false (https://github.com/sveltejs/language-tools/tree/master/packages/svelte-vscode#sveltepluginsvelteformatenable), o erro ainda ocorre? Ou a saída está cheia de erros de memória de qualquer maneira?
• Você tem um tsconfig.json ou jsconfig.json ? Se não, o que acontece se você adicionar um (pode ser apenas um simples)?

Olá @dummdidumm Obrigado pela resposta rápida!

Primeiro - a partir desta manhã eu abri algumas coisas para fazer testes para suas perguntas ... e parece ter desaparecido no ar. Clássico.

Aqui estão algumas respostas para você para a posteridade:

De quantos arquivos svelte / js estamos falando?

• Projetos pequenos (<10 arquivos): A pequena janela "Executando o Svelte Beta" aparece por <10 segundos, arquivos salvos e formatados
• Projetos maiores (> 10 arquivos): aqui é onde eu estava encontrando aquele problema. Essa janela aparece no canto inferior esquerdo e tenta e tenta por cerca de 20-30 segundos. Então kaput.

Isso acontece imediatamente após alguns segundos / minutos de trabalho com o projeto ou somente após algum tempo?
Até agora, é imediatamente. Abra um projeto, altere um arquivo, salve e as situações acima ocorrerão. E eu só percebi isso depois da atualização do VSCode ontem (ou antes). Embora o Svelte Beta tenha sido mais lento para salvar em geral do que a extensão anterior (cerca de 2-4 segundos antes da formatação e salvamento acontecer), se isso for útil.

Se você definir svelte.plugin.svelte.format.enable como false (https://github.com/sveltejs/language-tools/tree/master/packages/svelte-vscode#sveltepluginsvelteformatenable), o erro ainda ocorre?
Posso tentar na próxima vez que perceber que isso está acontecendo. Infelizmente, já que parou aleatoriamente agora, não acho que vá adiantar, heheh.

Você tem um tsconfig.json ou jsconfig.json?
Não .tsconfig ou .jsconfig em nenhum dos meus projetos. Se você tiver configurações simples para compartilhar, eu também poderia tentar na próxima vez.

Então, tudo bem que ele desapareceu, mas caramba, se não sabemos o problema agora, hehe.

Clássico 😄

Eu fiz a pergunta jsconfig.json / tsconfig.json porque tivemos um erro semelhante anteriormente em que o serviço de linguagem carregava muitos arquivos na inicialização porque estava encontrando outra configuração mais acima na árvore de arquivos (fora de a pasta do projeto) e usando isso - embora isso já deva ser corrigido.

Vou adicionar algum registro para obter o número de arquivos carregados na inicialização, bem como a cada minuto depois.

Parece bom - avisarei você se alguma coisa mudar! Estou brincando em um daqueles projetos de mais de 10 arquivos agora e tudo ainda está fluindo bem ...

Adicionamos medidas adicionais para evitar o inchaço inicial do arquivo. Se alguém ainda tiver alto uso de memória, informe aqui. Caso contrário, fecharei isso em algumas semanas.

@dummdidumm alguma atualização na extensão Atom?

Veja # 70 para informações e progresso sobre isso.

A exclusão de __sapper__ do observador VSCode interrompeu a extensão para ficar sem memória para mim.