Language-tools: Сильное использование памяти языковым сервером

Языковой сервер использует языковую службу машинописного текста за кулисами. Я предполагаю, что высокая память связана с тем, что машинописный текст пытается проанализировать все файлы, настроенные в jsconfig.json , для включения. Поскольку языковая служба машинописного текста находится в том же процессе, что и языковый сервер стройного языка, я не знаю, сколько памяти используется языковой службой машинописного текста.

Мне любопытно, насколько велика ваша папка __sapper__ . В моем проекте есть jsconfig.json включает около 200 исходных файлов js и использует только 150 МБ. Не могу представить, как ваша папка __sapper__ заставляет языковой сервер использовать более 2 ГБ памяти.

Для справки, вот репо моего проекта: b339c2a17e @ Innopoints / frontend

Я только что клонировал его, запустил сервер и получил следующее:

• 490 МБ, когда папка __sapper__ содержит сборку разработчика
• 730 МБ, когда папка __sapper__ содержит сборки для разработки и производства.

Вы можете попробовать скомпилировать его сами, чтобы воспроизвести это (обратите внимание, что сервер разработки не будет работать без переменных окружения, но это нормально, поскольку компиляция все равно будет успешной). Установите deps с помощью Yarn, скомпилируйте с помощью yarn dev а затем откройте любой файл .svelte в VS Code.

Кроме того, если это имеет какое-то значение, я использую VSCodium, а не обычный VS Code.

Есть ли способ указать SLS сканировать только файлы .svelte ? Я не думаю, что файлы .js/.ts действительно имеют отношение к анализу кода Svelte. Особенно те, которые не импортируются напрямую, например, папка __sapper__ .

Если нет, мне любопытно, как SLS ведет себя в отсутствие jsconfig.json . Как я уже упоминал, удаление этого файла возвращает потребление памяти до адекватных 150 МБ. И об этом определенно стоит упомянуть в README, потому что для меня, человека, который не очень хорошо знаком с методами TS, было очень большим сюрпризом, что, казалось бы, совершенно не связанный файл jsconfig.json вызывает такую ​​резкую разницу.

Да, мы должны добавить что-нибудь в документацию по этому поводу.

Сканирование файлов .ts / .js необходимо, чтобы предоставить вам intellisense от компактного до этих файлов. Вы не получили бы автозаполнение / переход к определению / наведению на них информации, если бы они не были включены.

Просто кажется, что папка __sapper__ не очень полезна для IntelliSense, поэтому, возможно, это игнорирование можно даже установить по умолчанию и при необходимости переопределить

У меня по-прежнему наблюдается использование памяти до 2 ГБ, но это очень сложно отследить. Похоже, что он просто взрывается в случайные моменты, когда я редактирую исходный код Svelte в этом проекте. Что бы вы посоветовали для уменьшения потребления памяти?

Языковой сервер обнаруживает компактные файлы и просматривает их по дереву файлов. Он также будет учитывать содержимое файла jsconfig / tsconfig. Исходя из вашего опыта («взрывается», а не «постоянно увеличивается»), я предполагаю, что прямо сейчас сервер каким-то образом доходит до точки, когда он загружает кучу несвязанных файлов, которые он не должен.
Вы можете заглянуть в VSCode Output-> Svelte и посмотреть, есть ли что-нибудь подозрительное (или просто скопируйте его сюда)

Сегодня это работает для меня, но вчера мне пришлось вручную убить процессы с тонкими языковыми инструментами после закрытия VS Code (не отвечал на SIGTERM).

На данный момент мне больше нечего добавить.

Насколько велик ваш проект? У вас есть tsconfig.json или jsconfig.json ?

@dummdidumm Не намного больше, чем шаблон

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

Так что и вы, и @illright используете

@dummdidumm Дайте мне знать, могу ли я чем-то помочь в расследовании. Возможно, есть способ запустить SLS через командную строку или что-нибудь еще более воспроизводимое, чем просто возиться в редакторе?

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

Только что я снова набрал 2,1 ГБ и SIGKILL отключил SLS. Вышесказанное можно увидеть в DevTools of Atom.

Ой, подождите, вы используете Atom? Какое расширение вы используете?

@dummdidumm У меня есть как Atom (с ide-svelte , ручное изменение языковой версии сервера), так и VSCodium (с Svelte Beta).

Вот результат вкладки VSCodium Svelte, когда произошел взрыв. Вроде бы убил и восстановил, но заморозка все равно была.

Хорошо, я понимаю, спасибо.

Похоже, взрыв произошел очень скоро после запуска.

Если бы вы сами немного поработали с расширением на местном уровне, это было бы здорово! Чтобы настроить расширение локально для VSCode (ium, надеюсь, должно быть таким же), сначала удалите его, а затем настройте локально, как описано здесь . На чем вы хотите сосредоточиться, так это на сервисе . Я предполагаю, что в какой-то момент он получает слишком много файлов, с которыми он должен иметь дело, что можно увидеть здесь . Если вы добавите консольный журнал выше (строка 72), в котором записываются файлы (возможно, с интервалом в 10 секунд, например, setInterval(() => console.log(JSON.stringify(Array.from(new Set([...files, ...snapshotManager.getFileNames(), ...svelteTsxFiles]), null , 3)), 10000) ), это может помочь в получении некоторой информации.

Таким образом, похоже, что snapshotManager.getFileNames() содержит кучу файлов, которые не должны просматриваться согласно jsconfig.json . Он также реагирует на изменение файла тем, что не загружает ничего из Sapper до тех пор, пока не произойдет сборка, но с этого момента файлы __sapper__/**/*.js заполняют память.

Хорошо, я думаю, это источник проблемы. Это объясняет внезапный взрыв, потому что все новые файлы были добавлены в список отслеживания.

Да, наверное, так оно и есть. Я думаю, нам нужно настроить, как TypescriptPlugin обрабатывает ts / js-onWatchedFilesChange. Может быть, сделайте это, как это делает vetur, и только удалите старые вещи, а не добавляйте новые. Или добавьте несколько вариантов наилучшего предположения, например __sapper__ / node_modules / dist которые следует игнорировать.

Я попробую это сделать.

Ужасный обходной путь, пока эта проблема не будет исправлена: найдите каталог расширений Svelte, откройте node_modules/svelte-language-server/dist/src/plugins/typescript/service.js и закомментируйте snapshotManager.getFileNames() :

Строка 69:

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

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

Вы теряете часть IntelliSense, но сохраняете подсветку синтаксиса, и, по крайней мере, производительность не падает случайным образом. И если вы хоть немного похожи на меня, этого должно быть достаточно :)

Дополнение к тому, что сказал @illright . обычно он находится в ~/.vscode/extensions или %userprofile%\.vscode \extensions\ в окнах.

Другой обходной путь - перейти к node_modules/svelte-language-server/dist/src/plugins/typescript/TypeScriptPlugin.js
Добавьте следующие строки в строку 237, где onWatchFileChanges start

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

этот метод является источником проблемы

Я создал PR №165. Не могли бы вы попробовать его при отладке и посмотреть, улучшилось ли оно?

@ jasonlyu123 Да, улучшение замечаю. Какое-то время возился с моим проектом, потребление памяти держалось под контролем. Восстановление Sapper также не вызывает переполнения памяти.

Примечание: под контролем = ~ 480 МБ в пике. Это достаточно мало, чтобы не повлиять на мою систему, но вы все равно можете посчитать это высоким потреблением памяти. У меня на машине 8 ГБ ОЗУ.

Боль настоящая 😭

Даже если мы по умолчанию исключаем __sapper__ , я все равно рекомендую поместить __sapper__ в исключение вашего tsconfig.json / jsconfig.json. Потому что мы используем наш собственный набор машинописных текстов. tsserver, используемый vscode, может все еще включать его.

@illright не могли бы вы проверить последнюю версию плагина? Сейчас должно быть лучше.

VS Code, как обычно, кажется гладким, используется около 400 МБ памяти. Есть ли шанс, что обновление SLS будет перенесено на расширение Atom? Это то место, где на днях я заметил падение производительности.

@orta занимается переносом плагина Atom в это репо. После этого вы должны получить обновления языкового сервера.

@ rob-balfre, у вас тоже снизилось использование памяти? Если нет, не могли бы вы указать свою настройку?

У меня были те же проблемы, добавление transpileOnly в препроцессор машинописного текста, похоже, значительно улучшило ситуацию.
В вашем svelte.config.js
`` ''
const sveltePreprocess = require ("стройный препроцесс");

module.exports = {
препроцесс: sveltePreprocess ({
машинописный текст: {
transpileOnly: правда,
},
}),
// ... другие стройные параметры (необязательно)
};

Я заметил это вскоре после недавнего обновления VSCode. Небольшие проекты не кажутся такой большой проблемой (хотя сохранение все еще занимает немного больше времени, чем обычно). Сохранение зависнет, затем файл сохранится и отформатируется. После этого вроде нормально. И это только для небольших проектов. Это как будто он пытается проиндексировать папку проекта или что-то в этом роде и зависает? Большие проекты с большим количеством файлов и т. Д. Заканчиваются зависанием и ошибками.

Использование памяти / ошибка у меня возникает при сохранении файла Svelte. Он просто зависает и висит с таким сообщением внизу справа:

Вот окно 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  

Это также происходит в этом более крупном проекте Svelte, где сохраняются другие файлы (.js и т. Д.). Если я отключу Svelte Beta, все будет хорошо (за исключением того, что теперь файлы Svelte не распознаются.

Я не хотел начинать новый выпуск, поскольку он кажется связанным с этим, но абсолютно могу, если это не имеет отношения.

Спасибо!

Спасибо за информацию. У меня есть еще несколько вопросов, чтобы сузить круг вопросов:

• О скольких файлах svelte / js идет речь?
• Это происходит сразу через несколько секунд / минут работы с проектом или только через какое-то время?
• Если вы установите для svelte.plugin.svelte.format.enable значение false (https://github.com/sveltejs/language-tools/tree/master/packages/svelte-vscode#sveltepluginsvelteformatenable), возникнет ли ошибка? Или все равно вывод завален ошибками памяти?
• У вас есть tsconfig.json или jsconfig.json ? Если вы этого не сделаете, что произойдет, если вы добавите один (может быть простой)?

Привет, @dummdidumm Спасибо за быстрый ответ!

Во-первых, сегодня утром я открыл кое-что для проверки ваших вопросов ... и, похоже, он растворился в воздухе. Классический.

Вот несколько ответов для потомков:

О скольких файлах svelte / js идет речь?

• Небольшие проекты (<10 файлов): маленькое окно «Запуск Svelte Beta» открывается на <10 секунд, файлы сохраняются и форматируются.
• Большие проекты (> 10 файлов): здесь я столкнулся с этой проблемой. Это окно появляется в нижнем левом углу и пытается в течение примерно 20-30 секунд. Тогда капут.

Происходит ли это сразу через несколько секунд / минут работы с проектом или только через какое-то время?
Пока что сразу. Откройте проект, измените файл, сохраните и вышеперечисленные ситуации. И я это заметил только после обновления VSCode вчера (или накануне). Хотя Svelte Beta в целом сохранял медленнее, чем предыдущее расширение (примерно за 2-4 секунды до форматирования и сохранения), если это было полезно.

Если для svelte.plugin.svelte.format.enable установлено значение false (https://github.com/sveltejs/language-tools/tree/master/packages/svelte-vscode#sveltepluginsvelteformatenable), возникает ли ошибка?
Я могу попробовать это в следующий раз, когда замечу, что это происходит. К сожалению, поскольку он случайно остановился только сейчас, я не думаю, что это принесет пользу, хехех.

У вас есть tsconfig.json или jsconfig.json?
Ни в одном из моих проектов нет .tsconfig или .jsconfig . Если у вас есть какие-то простые настройки, я мог бы попробовать это в следующий раз.

Итак, в общем, ура, что он исчез, но, черт возьми, если мы не знаем проблему сейчас, хе-хе.

Классический 😄

Я задал вопрос jsconfig.json / tsconfig.json потому что раньше у нас была аналогичная ошибка, когда языковая служба загружала слишком много файлов при запуске, потому что находила другую конфигурацию дальше по дереву файлов (за пределами папку проекта) и используя это - хотя это должно быть исправлено к настоящему времени.

Я добавлю запись в журнал, чтобы получать загруженное количество файлов при запуске, а также каждую минуту после этого.

Звучит хорошо - я дам знать, если что-нибудь изменится! Я сейчас играю в одном из этих> 10 файловых проектов, и все по-прежнему идет гладко ...

Мы добавили дополнительные меры для предотвращения первоначального раздувания файлов. Если у кого-то по-прежнему наблюдается высокий уровень использования памяти, сообщите об этом здесь. В противном случае я закрою это через несколько недель.

@dummdidumm есть ли обновления для расширения Atom?

См. # 70 для информации и прогресса в этом.

Исключение __sapper__ из наблюдателя VSCode остановило расширение памяти для меня.