Language-tools: استخدام ذاكرة كثيف لخادم اللغة

يستخدم خادم اللغة خدمة اللغة المطبوعة خلف الكواليس. أعتقد أن الذاكرة العالية هي لأن الكتابة المطبوعة تحاول تحليل جميع الملفات التي تم تكوينها ، في jsconfig.json ، ليتم تضمينها. نظرًا لأن خدمة اللغة المطبوعة في نفس العملية مثل خادم اللغة svelte ، لا أعرف مقدار الذاكرة المستخدمة بواسطة خدمة اللغة المطبوعة.

لدي فضول لمعرفة حجم مجلد __sapper__ . يحتوي مشروعي على jsconfig.json وقد تم تعيينه ليشمل حوالي 200 ملف مصدر js ويستخدم فقط 150 ميجابايت. لا يمكنك تخيل كيف يتسبب مجلد __sapper__ في أن يستخدم خادم اللغة أكثر من 2 جيجابايت من الذاكرة.

كمرجع ، ها هو الريبو الخاص b339c2a17e @ Innopoints / frontend

لقد قمت باستنساخه حديثًا وتشغيل الخادم وحصلت على ما يلي:

• 490 ميغابايت عندما يحتوي المجلد __sapper__ على إصدار dev
• 730 ميغابايت عندما يحتوي المجلد __sapper__ على إصدارات التطوير والإنتاج

يمكنك محاولة تجميعها بأنفسك لمحاولة إعادة إنتاج هذا (لاحظ أن خادم dev لن يعمل بدون متغيرات البيئة ، لكن هذا جيد ، لأن التجميع سينجح على أي حال). قم بتثبيت 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 لتزويدك بمعلومات من الرشيقة إلى هذه الملفات. لن تحصل على الإكمال التلقائي / انتقل إلى معلومات التعريف / التمرير لهذه ، إذا لم يتم تضمينها.

يبدو الأمر وكأن المجلد __sapper__ ليس ذا فائدة كبيرة لـ IntelliSense ، لذلك ربما يمكن تعيين هذا التجاهل افتراضيًا وتجاوزه إذا لزم الأمر

ما زلت أحصل على استخدامات للذاكرة تصل إلى 2 جيجابايت ، ولكن من الصعب جدًا تتبعها. يبدو أنه ينفجر في أوقات عشوائية بينما أقوم بتحرير مصدر Svelte في هذا المشروع. ما الذي يمكن أن تنصح به لخفض استهلاك الذاكرة؟

يكتشف خادم اللغة ملفات svelte وسيرسل شجرة الملفات من ذلك. سيتم أيضًا تكريم الأشياء الموجودة في jsconfig / tsconfig. من خبرتك ("تفجير" ، وليس "زيادة مطردة") ، أعتقد الآن أن الخادم يصل بطريقة ما إلى النقطة التي يقوم فيها بتحميل مجموعة من الملفات غير ذات الصلة والتي يجب ألا يفعلها.
يمكنك البحث في إخراج VSCode-> Svelte ومعرفة ما إذا كان هناك أي شيء مريب (أو فقط نسخه هنا)

إنه يتصرف بالنسبة لي اليوم ، ولكن بالأمس اضطررت إلى إيقاف عمليات أدوات اللغة الرشيقة يدويًا بعد إغلاق VS Code (لم يكن يستجيب لـ SIGTERM).

ليس لدي الكثير لأضيفه في هذا الوقت.

ما هو حجم مشروعك؟ هل لديك tsconfig.json أو jsconfig.json ؟

dummdidumm ليس أكبر بكثير من قالب sapper. لدي tsconfig.json أساسي لم يتغير منذ أن واجهت المشكلة.

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

لذلك أنت و illright تستخدمان sapper ولديهما استخدام ذاكرة عالية. ربما نمط .. سوف تضطر إلى التحقيق في هذا.

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 جيجا بايت و SIGKILLed SLS. يمكن رؤية ما ورد أعلاه في DevTools of Atom

أوه انتظر ، أنت تستخدم أتوم؟ ما هو الامتداد الذي تستخدمه؟

dummdidumm لدي كل من Atom (مع ide-svelte ، مع إصدار خادم اللغة يدويًا) و VSCodium (مع Svelte Beta).

إليك ناتج علامة التبويب Svelte الخاصة بـ VSCodium عند حدوث الانفجار. يبدو أنه قتلها وتعافى ، لكن التجميد كان لا يزال هناك.

حسنًا ، فهمت ، شكرًا.

يبدو أن الانفجار حدث بعد وقت قصير جدًا من بدء التشغيل.

إذا كنت ستفحص نفسك قليلاً مع الامتداد محليًا ، فسيكون ذلك رائعًا! لإعداد الامتداد محليًا لـ 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)));

تفقد بعض التحسس الذكي ، لكنك تحتفظ بإبراز بناء الجملة ولا ينخفض ​​الأداء بشكل عشوائي على الأقل. وإذا كنت مثلي ، فيجب أن يكون ذلك جيدًا بما يكفي لتجاوزه :)

استكمالاً لما قاله ~/.vscode/extensions أو %userprofile%\.vscode \extensions\ في النوافذ.

حل آخر هو الانتقال إلى node_modules/svelte-language-server/dist/src/plugins/typescript/TypeScriptPlugin.js
أضف الأسطر التالية إلى السطر 237 حيث يبدأ onWatchFileChanges

        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 = تتطلب ("svelte-preprocess") ؛

module.exports = {
preprocess: sveltePreprocess ({
مطبوعة: {
transpileOnly: صحيح ،
} ،
}) ،
// ... خيارات svelte الأخرى (اختياري)
} ؛

لقد لاحظت هذا أيضًا بعد وقت قصير من تحديث 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 ثانية تقريبًا. ثم kaput.

هل يحدث ذلك على الفور بعد بضع ثوان / دقائق من العمل مع المشروع أم بعد مرور بعض الوقت فقط؟
حتى الآن إنه على الفور. افتح مشروعًا ، وقم بتغيير ملف ، وحفظه ، وتحدث المواقف المذكورة أعلاه. ولقد لاحظت ذلك فقط بعد تحديث 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 لأننا واجهنا خطأً مماثلاً سابقًا حيث كانت خدمة اللغة ستحمّل عددًا كبيرًا جدًا من الملفات عند بدء التشغيل لأنها كانت تبحث عن تهيئة أخرى أعلى شجرة الملف (خارج مجلد المشروع) واستخدام ذلك - على الرغم من أنه يجب إصلاح ذلك الآن.

سأضيف بعض التسجيل للحصول على عدد الملفات المحملة عند بدء التشغيل وكذلك كل دقيقة بعد ذلك.

يبدو جيدًا - سأعلمك إذا تغير أي شيء! أنا ألعب في واحد من تلك المشاريع العشرة ملفات الآن ولا يزال كل شيء سلسًا ...

أضفنا إجراءات إضافية لمنع تضخم الملفات الأولية. إذا كان أي شخص لا يزال يواجه استخدامًا عاليًا للذاكرة ، فيرجى الإبلاغ هنا. وإلا سأغلق هذا في غضون أسابيع قليلة.

dummdidumm أي تحديثات على امتداد Atom؟

انظر # 70 للحصول على معلومات والتقدم في هذا الشأن.

أدى استبعاد __sapper__ من VSCode watcher إلى إيقاف الامتداد للخروج من الذاكرة بالنسبة لي.