Yarn: بحاجة إلى تحسين كبير لنظام التشغيل Windows

+1

مرحباOshotOkill! شكرا لتجربة الغزل. هل تستخدم Cygwin أو WSL ("Bash on Ubuntu على Windows")؟ من المعروف أن كلاهما لهما أداء سيئ جدًا لقرص الإدخال / الإخراج.

أيضًا ، يحتوي React Native على عدد كبير من الملفات ، لذا فإن نسخها إلى node_modules بطيء جدًا ، وقرص الإدخال / الإخراج للكثير من الملفات الصغيرة على Windows يكون بشكل عام أبطأ من Mac OS (وهو نفسه أبطأ من Linux ext4). لدينا مهمة لتجربة الروابط الصلبة (# 499) والتي يجب أن تحسن الأداء في هذا السيناريو.

لا توجد ذاكرة تخزين مؤقت ونفس بيئة الشبكة

التحسن الرئيسي مع Yarn هو عندما يكون لديك ذاكرة تخزين مؤقت دافئة (أي بعد تثبيت حزمة مرة واحدة على الأقل) ، ولكن مع React Native ، سيكون العدد الهائل من الملفات أيضًا سببًا لبعض البطء.

@ Daniel15 كلا ، أنا لا أستخدم Cygwin / MinGW / MSYS2 أو WSL (فشل الأخير بسبب خطأ معقد).

وفقًا لوصفك ، يمكنني أن أفترض أن المشكلة ناتجة عن نظام الملفات (NTFS) ، أليس كذلك؟ حتى في حالة وجود ذاكرة تخزين مؤقت دافئة ، تظل عملية النسخ أبطأ بكثير من MacOS.

آمل أن تتمكن فرق التطوير من التوصل إلى حل في أسرع وقت ممكن. شكر.

أنا أرى نفس الشيء.

هل التثبيت ، ومسح node_modules ، التثبيت

يستغرق MacBookPro 17 ثانية ، ويستغرق جهاز Windows الخاص بي 122 ثانية.

أشار شخص ما إلى أن هذا قد يكون مرتبطًا بوحدات node_modules التي تفحص برامج مكافحة الفيروسات وذاكرة التخزين المؤقت العالمية للغزل بشكل مستمر. هل يمكنك محاولة تعطيله لتلك المجلدات؟

cpojer أعتقد أنهم على حق. ليس لدي أي برنامج مكافحة فيروسات على جهازي باستثناء برنامج Windows Defender المثبت مسبقًا ، لذلك حظرت فحص مجلد ذاكرة التخزين المؤقت العالمية ومجلد مشروعي وأجريت بعض الاختبارات:

الافتراضي: 128.08 ثانية

لا يوجد مسح ضوئي لمجلد ذاكرة التخزين المؤقت: 104.43 ثانية

لا يوجد مسح ضوئي لمجلد المشروع: 78.28 ثانية

لا يوجد مسح ضوئي لمجلد ذاكرة التخزين المؤقت ومجلد المشروع: 53.48 ثانية

على الرغم من أنه أبطأ من Mac لمدة 10 + ثانية ، إلا أنه يتمتع بدعم كبير.

يجب أن يتم إبلاغ ذلك من المستندات الرسمية على ما أعتقد.

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

مسكة جيدة! لقد نسيت هذا تمامًا لأن لدي بالفعل c:\src القائمة البيضاء على أجهزة الكمبيوتر الخاصة بي.

OshotOkill - هل ترغب في إرسال طلب سحب إضافة ملاحظة حول تطبيقات مكافحة الفيروسات إلى موقع الويب ، في إرشادات تثبيت Windows؟ إليك الملف الذي تريد تعديله: https://github.com/yarnpkg/website/blob/master/en/docs/_installations/windows.md (يمكنك تحريره مباشرة على Github). سيكون موضع تقدير 😄

لم أكن دقيقًا مثل OshotOkill ، لكنني أضفت استثناءات

@ Daniel15 PR جاهز. اعتذر عن لغتي الإنجليزية الضعيفة.

تم دمج العلاقات العامة. أغلق هذا العدد.

لا يزال هذا بطيئًا بشكل مؤلم على النوافذ ، حتى أنه يتم إلغاء تنشيط برنامج مكافحة الفيروسات و Windows defender. لا أعتقد أنها مجرد مشكلة تتعلق بالبيئة (مثل حل مكافحة الفيروسات هذا) ، لكن يبدو أن الغزل يحاول نسخ جميع الملفات ، 1 × 1 حتى إذا قمت بتثبيت بعض التبعية غير ذات الصلة.

لماذا لا تقوم فقط بحذف / نسخ الملفات التي تحتاج إلى تغيير؟ إذا كان لدي webpack مثبتًا ولم يتم تعديله عند تثبيت rimraf ، فلا يجب نسخه مرة أخرى من ذاكرة التخزين المؤقت إلى مجلد node_modules المحلي.

لقد قمت بإنشاء مقال StackOverflow حول هذا أيضًا: http://stackoverflow.com/questions/40566222/yarn-5x-slower-on-windows

بالمناسبة في معايير Ubuntu (المزدوجة التمهيد) الخاصة بي ، كنت أستخدم نفس محرك أقراص NTFS الذي يعمل عليه Windows عادةً ؛ ولا يزال سريعًا هناك.

أعطتني إضافة node.exe إلى استثناءات Windows Defender زيادة هائلة في الأداء http://126kr.com/article/1884rsed7l

سأحاول بالتأكيد هذا!

يبدو أنه يحسن السرعة قليلاً 212 -> 170 ثانية
لذلك يبدو أنه يساعد ، لكن لا يزال من الممكن تحسينه ، لأنه لا يزال أبطأ بأكثر من 3 مرات من Linux

هناك مشكلة أخرى لاحظتها - تحاول خدمة الفهرسة على Windows فهرسة كل ملف في node_modules.
لا أحتاجه حقًا على الإطلاق ، لذلك قمت بتعطيله http://www.softwareok.com/؟seite=faq-Windows-10&faq=53 وحصلت على تعزيز آخر للأداء.

لم يتم تعيين النوافذ الخاصة بي على فهرسة المسار المعني ، لذلك لا يزال ذلك لا يحل المشكلة.

لتلخيص ، هناك 4 طرق لتحسين الأداء:

• إدراج مجلد المشروع في القائمة البيضاء من AV
• Whiteilst دليل ذاكرة التخزين المؤقت للغزل ((٪ LocalAppData٪ Yarn)) من AV
• إضافة node.exe إلى استثناءات Windows Defender
• تعطيل خدمة الفهرسة على Windows في المجلد node_modules

Altiano نعم ، ولكن لا يكفي الحصول على أداء قريب من نظام Mac / Linux

يبدو أنه من الغريب أنه سيتعين عليك تعطيل AV أو الفهرسة في الدلائل لجعل الغزل أسرع أو أسرع من npm. بعد كل شيء ، ليس عليك القيام بذلك من أجل npm. قررت أن أجرب الغزل لأنه ذكر أنه سريع وأن عمليات التثبيت دون اتصال جعلت الترميز بدون اتصال بالشبكة أمرًا معقولاً. لا توجد طريقة لتحسين الارتباط؟

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

أنا شخصياً أقترح سرد تكوينات الأجهزة حول جهاز الاختبار الخاص بك وتحميل بعض الصور ذات الصلة. يمكن أن يكون هناك العديد من العناصر الأخرى غير ذات الصلة التي تحدث فرقًا كبيرًا بين الأنظمة الأساسية بدلاً من Yarn نفسها ، على سبيل المثال ، عادةً ما يكون الأداء المعياري لـ SSD على MacBook أفضل بكثير من جهاز Windows.

OshotOkill كما قلت سابقًا ، لقد حصلت على أداء أبطأ

دعنا نتعرف على سبب ذلك.
هل يمكن أن يكون NTFS يعمل بشكل أبطأ على عدد كبير من الملفات التي يتم نقلها أثناء التثبيت؟

هل يمكن لأي شخص أن يتشارك في طريقة لإعادة عرض هذا على جهاز واحد؟
على سبيل المثال ، تستغرق حزمة package.json معينة مثبتة على كمبيوتر محمول يعمل بنظام Windows X ثانية ولكنها تعمل في VirtualBox Ubuntu X-20٪ ثانية.

amcsibestander كما هو الحال في كثير من الأحيان، EXT4 / XFS وأسرع في حين نسخ كميات كبيرة من الملفات الصغيرة. ومع ذلك ، فإن نظام NTFS ليس أبطأ بكثير. لقد قمت للتو بتنظيف ذاكرة التخزين المؤقت واختبرتها مرة أخرى باستخدام أحدث إصدار من Yarn and Node (0.19.1 و 7.5.0):

النتيجة قريبة جدًا من جهاز MacBook أثناء تثبيت react-native . كل ما فعلته هو إضافة المجلدات ذات الصلة وعملية Node.exe إلى القائمة البيضاء.

كنت أواجه هذه المشكلة بنفسي حتى أدرجت عمليات node.exe و yarn.exe في القائمة البيضاء في Windows Defender ، إلى جانب دليل مشروعي. لم أقم بتعطيل فهرسة البحث على الإطلاق ، ولم أقم بإدراج دليل ذاكرة التخزين المؤقت في القائمة البيضاء. ارتفعت أوقات التثبيت من 190+ ثانية في مشروع متوسط ​​الحجم إلى حوالي 25 ثانية من ذاكرة تخزين مؤقت نظيفة. إن جهاز Ubuntu الخاص بي أسرع قليلاً من ذلك ، ولكن فقط في 5-10 ثوانٍ.

تكوين الأجهزة:
512 جيجا بايت SSD
12 جيجا رام
معالج AMD FX-8350 ثماني النواة بسرعة 4.01 جيجاهرتز
Windows 10 64 بت ، الإصدار 14986.

لقد أجريت للتو بعض الاختبارات السريعة على نظامي الخاص. لقد حصلت على Linux Mint و Windows 10 مزدوج التمهيد من نفس SSD. قمت بتنظيف ذاكرة التخزين المؤقت الخاصة بي ، وحذفت node_modules وقمت بتشغيل yarn في مشروع vue هذا.

لينكس منت: _12.22s_

Windows 10 (لا توجد قائمة بيضاء): _64.32s_

Windows 10 (مع قائمة بيضاء): _42.58 s_

كانت هذه استثناءات Windows Defender التي كنت نشطة:

بينما يبدو أن القائمة البيضاء لها تأثير كبير ، إلا أنها لم تقترب من مطابقة السرعة على نظام Linux.

تحرير: بالنسبة لـ bestander ،

| نظام التشغيل | الحساب | بيانات طبيعية |
| --- | --- | --- |
| لينكس منت | 12.22 / 12.22 | 1 |
| نظام التشغيل Windows 10 | 64.32 / 12.22 | 5.2635 |
| Windows 10 (مع القائمة البيضاء) | 42.58 / 12.22 | 3.4845 |

keawade كان لدي 26.48 ثانية لتثبيت مشروعك من ذاكرة تخزين مؤقت نظيفة ، و 13.58 ثانية لتثبيته مع ذاكرة التخزين المؤقت.

مجرد spitballing هنا ، أنا أستخدم Yarn.cmd من مثبت MSI ويبدو أنك تستخدم Yarn مثبتًا من NPM. أتساءل عما إذا كان هناك تناقض بينهما؟

nozzlegear بينما قد يكون ذلك ممكنًا ، أعتقد أن هذا أقل احتمالًا مما يكون بسبب اختلاف اتصالات الإنترنت.

نحن بحاجة للقضاء على الشبكة من هذا.
يمكنني حاليًا اختبار هذا الريبو على أحدث إصدار من Windows 10 مع تمكين ميزة "Linux على Windows".
يستغرق كلاهما عبر CMD و Bash مع تثبيت ذاكرة التخزين المؤقت الرئيسية حوالي 27-29 ثانية على معالج 2 core i7.

keawade ، هل يمكنك إجراء نفس الاختبار مع إزالة node_modules ولكن ذاكرة التخزين المؤقت في مكانها؟

لا يمكنني تثبيت نظام تشغيل ثانٍ على الجهاز الذي أملكه حتى الآن.
هل يمكن لأي شخص التحقق مما إذا كان تشغيل Windows و Linux في مربع افتراضي يعطي نتائج مختلفة؟

لقد قمت ببناء المعلم الحالي باستخدام الطوابع الزمنية https://github.com/yarnpkg/yarn/releases/download/v0.21.0-pre/yarn-0.21.0-0.js

هل يمكنك استخدامه للتثبيت مع العلم --verbose ؟

على سبيل المثال

node /Users/bestander/work/yarn/artifacts/yarn-0.21.0-0.js install --verbose

يجب أن يعطي الطوابع الزمنية لجميع عمليات FS

البيانات بدون تنظيف المخابئ

_ ملاحظة: يتم تسجيل هذه البيانات على نظام التشغيل المزدوج. جميع الأجهزة مطابقة لهذه الاختبارات.

| نظام التشغيل | متوسط ​​الوقت | تطبيع |
| ----------------------------- | ---------- | -------- ---- |
| لينكس منت | 5.598 ثانية | 1.00000 |
| Windows 10 (مع القائمة البيضاء) | 12.119 ثانية | 2.16488 |
| Windows 10 (بدون القائمة البيضاء) | 31.578 ثانية | 5.64094 |

_متوسط ​​الوقت هو المتوسط ​​عبر مجموعة من 10 اختبارات_

بيانات Linux Mint الخام

[5.47, 5.40, 5.84, 5.96, 5.55, 5.48, 5.40, 5.57, 5.81, 5.50]

بيانات Windows 10 الأولية

مع القائمة البيضاء

[11.91, 11.87, 11.88, 12.07, 11.81, 12.02, 12.39, 12.49, 12.28, 12.47]

بدون قائمة بيضاء

[30.85, 31.52, 31.39, 31.46, 31.14, 31.41, 34.24, 31.09, 31.40, 31.28]

المنهجية

لقد استخدمت برنامج PowerShell النصي هذا لإنشاء جميع البيانات المعروضة هنا. يقوم البرنامج النصي باستنساخ هذا الريبو وتشغيل 10 تكرارات للأمر yarn ، مع حذف node_modules بعد كل تكرار.

@ bestander ، لقد قمت بتحديث

عظيم ، شكرا لمزيد من البيانات.
هل يمكنك تجربة إصدار --verbose مع yarn.js مع طوابع زمنية لكلا نظامي التشغيل؟
سيعطينا فكرة جيدة عن المكان الذي يقضي فيه الوقت.

يا للعجب ، هذا كثير من قطع الأشجار! هل تريد 10 عمليات تشغيل لكل مجموعة نظام تشغيل / قائمة بيضاء أم واحدة لكل مجموعة جيدة بما يكفي؟

@ bestander هنا تذهب! واحد من كل نوع.

ملاحظة جانبية: إذا حاولت تحميل حوالي 30 ميجابايت من النص الخام إلى مجموعة جوهر واحدة ، فستحصل على خطأ nginx 405. 😆

~ لينكس منت ~
~ Windows 10 مع استثناءات وبنظافة ~
~ Windows 10 مع استثناءات وبدون _clean_ ~
~ Windows 10 نظيف وبدون استثناءات
~ Windows 10 بدون _استثناءات _ و _ بدون _ نظيف ~

VerboseLogs.tar.gz

تحرير: إزالة البيانات وتحميل الملفات المضغوطة.

يتضح أنه إذا حاولت تحميل حوالي 30 ميجابايت من النص الخام إلى مجموعة جوهر واحدة ، فستحصل على خطأ nginx 405. 😆

يمكنك ضغط الملفات (bzip2 أو 7-Zip) وإرفاقها هنا ... يتم ضغط النص العادي جيدًا :)

@ Daniel15 نقطة جيدة ، VerboseLogs.tar.gz

تشغيل واحد سيكون جيدًا :)

لقد قارنت LinuxMint.txt مقابل Windows10NoClean.txt

لينكس:

• تبدأ مرحلة الربط عند 1.156 ثانية
• تم إنشاء جميع المجلدات داخل node_modules عند 1.968.200
• تم نسخ الملف الأخير في 3.873 ثانية
• تتم الإنشاءات في 3 ثوانٍ أخرى

شبابيك

• تبدأ مرحلة الارتباط عند 2.779 ثانية
• تم إنشاء جميع المجلدات داخل node_modules عند 4.83
• تم نسخ الملف الأخير في 32.853
• تتم الإنشاءات في 3 ثوانٍ أخرى

من الواضح أن التسجيل المطول يؤثر على وقت التنفيذ على Windows (12 -> 35 ثانية) ولكن ليس على Linux (نفس 6 ثوانٍ).

من بين المعايير التي وجدتها على الإنترنت ، عادةً ما يتفوق Linux EXT3 FS على نظام NTFS عندما يتم نسخ الكثير من الملفات.
أتساءل عما إذا كان هذا هو الحد الذي يتعين علينا مواجهته.

keawade ، هل تختلف السرعات عند استخدام npm @ 3 على نظامي التشغيل Windows و Linux؟

بعض الأفكار:

• قد يكون Windows سيئًا عند النسخ المتزامن ، فنحن نقوم بنسخ الملفات في 4 سلاسل. ربما تفعل ذلك مترابطة واحدة؟
• ربما استخدم غلاف robocopy في Windows https://github.com/mikeobrien/node-robocopy
• نستخدم readstream.pipe.writestream لنسخ الملفات ، ربما يكون غير فعال على Windows

إذا كنت حريصًا على التجربة ، فاستبدل 4 بـ 1 في https://github.com/yarnpkg/yarn/blob/master/src/util/fs.js#L322 ومعرفة ما إذا يصبح النسخ المترابط المفرد أسرع على النوافذ

اختبارات الخيط

بناءً على طلب bestander ، قمت yarnpkg/yarn وعدلت السطر 322 من src/util/fs.js ، واستبدلت 4 بـ 1 . ثم استخدمت yarn run build لإنشاء المشروع وقمت بإجراء 10 اختبارات مع هذا الإصدار باستخدام yarn.cmd الذي تم تجميعه بواسطة الإصدار. هذه هي النتائج.

| | متوسط ​​الوقت | تطبيع |
| ---------------------------- | ---------- | --------- --- |
| Windows 10 (مع القائمة البيضاء) | 12.119 ثانية | 1.00000 |
| موضوع نسخة واحدة | 16.927 ثانية | 1.39673 |
| خيط نسخة واحدة + تنظيف | 42.268 ثانية | 3.48775 |

_متوسط ​​الوقت هو المتوسط ​​عبر مجموعة من 10 اختبارات_

يبدو أن استخدام خيط واحد فقط لنسخ الملفات يؤدي إلى أوقات تثبيت أبطأ قليلاً.

مسودة بيانات

Windows 10 (مع القائمة البيضاء)

هذه البيانات من اختبار سابق

نسخة واحدة الموضوع

[15.72, 17.43, 15.16, 17.21, 17.83, 17.47, 16.68, 16.58, 16.93, 18.26]

نسخة واحدة الموضوع + تنظيف

[37.68, 40.10, 43.20, 46.18, 40.84, 40.58, 39.69, 47.93, 42.45, 44.03]

شكرا ، keawade.
هل يمكنك التحقق من افتراضي أن NTFS قد يكون أبطأ في نسخ عدد كبير من الملفات من Linux FS؟

قم بقياس النسخ عبر node_modules المثبتة على الجهاز الطرفي إلى موقع آخر في كل من Linux Mint و Windows 10 ، من فضلك.

من الضروري أيضًا اختبار النسخة باستخدام robocopy مع الخيار /mt (نسخ متعددة الخيوط)

أود أيضًا الإبلاغ عن خطأ محتمل تم الإبلاغ عنه ، حيث يستغرق كل yarn add أو yarn remove حوالي 30-40 دقيقة. يبدو أنه ينسخ جميع التبعيات مرة أخرى ، وبما أنني على Windows ، فإن هذا يستغرق وقتًا طويلاً. راجع المشكلة المرتبطة:

https://github.com/yarnpkg/yarn/issues/2460

kumarharsh # 2458 استغرق الأمر 28 ثانية لإنهاء التثبيت.

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

نسخ الاختبارات

لقد استخدمت هذا البرنامج النصي لتشغيل 10 نسخ متكررة على كل من Linux Mint و Windows 10. لقد قمت بنسخ هذا الريبو بعد تشغيل yarn في الدليل. هذه هي نتائجي.

| نظام التشغيل | متوسط ​​الوقت | تطبيع |
| ------------ | ------------ | ------------ |
| لينكس منت | 1527.4620 | 1.00000 |
| نظام التشغيل Windows 10 | 53676.3155 | 35.14085 |

هذا الفارق الزمني مجنون. تمت هذه النسخ بنسخ الملفات من مكان إلى آخر على نفس SSD.

مسودة بيانات

لينكس النعناع

TotalMilliseconds
-----------------
        1515.3961
        1513.9469
        1540.3275
        1527.2777
        1514.6029
        1521.3711
        1512.0628
        1547.8331
        1518.1499
        1563.6521

نظام التشغيل Windows 10

TotalMilliseconds
-----------------
       55729.4968
       55915.5972
       53427.5155
       51624.6760
       52191.4177
       53556.4542
       53562.5533
       53527.9015
       53610.6127
       53616.9302

ليس لدي الوقت الآن لاختبار robocopy ولكن يمكنني الحصول على هذه البيانات هذا المساء بعد العمل.

اختبار Robocopy

لقد استخدمت هذا البرنامج النصي لتشغيل 10 نسخ متكررة على كل من Linux Mint و Windows 10. لقد قمت بنسخ هذا الريبو بعد تشغيل yarn في الدليل. هذه هي نتائجي.

| نظام التشغيل | متوسط ​​الوقت | تطبيع |
| ----------------------- | ------------ | ------------ |
| لينكس منت | 1527.4620 | 1.00000 |
| نظام التشغيل Windows 10 | 53676.3155 | 35.14085 |
| Windows 10 (Robocopy) | 58089.7457 | 38.03024 |

كان أداء Robocopy أسوأ قليلاً من النسخة العادية.

مسودة بيانات

قيم Linux Mint و Windows 10 مأخوذة من الاختبارات السابقة

TotalMilliseconds
-----------------
       56935.3304
       58234.8084
       57838.7956
       56731.7850
       58380.1805
       58097.6040
       59161.0365
       59062.9404
       58363.5527
       58091.4234

keawade ، هل يمكنك التحقق من أن فهرسة الملف و Defender لا يتداخلان مع النسخة؟
يمكن أن تتورط Afaik حتى لأمر cp.

تحقق مما هو نشط في إدارة المهام عند اكتمال النسخ.
وربما فقط قم بإيقاف تشغيل هذه الخدمات للاختبار

اختبارات الفهرسة والمدافع

أجريت الاختبارات في ظل الشروط التالية:

• مع ويندوز ديفندر المعوقين
• مع تعطيل خدمة فهرسة Windows
• مع _both_ تعطيل خدمة Windows Defender و Windows Indexing
• مع تعطيل كل من Windows Defender وخدمة فهرسة Windows وتنظيف ذاكرة التخزين المؤقت Yarn

لتعطيل Windows Defender ، قمت بإيقاف تشغيل Real-time protection ضمن لوحة إعدادات Windows Defender .

لتعطيل فهرسة Windows ، أوقفت خدمة Windows Search في لوحة تحكم الخدمات .

_ ملاحظة: عند تمكين Windows Defender ، لم يتم إدراج أي استثناءات_

لقد استخدمت هذا البرنامج النصي لتشغيل 10 نسخ متكررة على كل من Linux Mint و Windows 10. قمت بنسخ هذا الريبو بعد تشغيل yarn في الدليل. هذه هي نتائجي.

ملخص

يبدو أنه بينما يكون لفهرسة Windows (خدمة البحث) تأثير على عمليات النسخ والغزل ، فإن التأثير الأكبر يأتي من Windows Defender.

نسخ

| نظام التشغيل | متوسط ​​الوقت | تطبيع |
| -------------------------------------------- | ---- -------- | ------------ |
| لينكس منت | 1527.4620 | 1.00000 |
| Windows 10 (بدون مدافع) | 7301.4307 | 4.78011 |
| Windows 10 (بدون فهرسة) | 10307.0794 | 6.74787 |
| Windows 10 (بدون مدافع ، بدون فهرسة) | 7044.1393 | 4.61166 |
| Windows 10 Robo (بدون مدافع ، بدون فهرسة) | 10094.8358 | 6.60889 |

الفهرسة يوفر تعطيل الفهرسة ومكافحة الفيروسات بالكامل دفعة قوية للأداء عند نسخ الملفات.

غزل

نظرًا لأن النتائج المذكورة أعلاه كانت واضحة جدًا ، فقد اعتقدت أنه من المحتمل أن نستخدم بيانات عن أداء Yarn في ظل هذه الظروف أيضًا.

لقد استخدمت هذا البرنامج النصي لتشغيل 10 تكرارات من yarn على كل من Linux Mint و Windows 10. لقد قمت باستنساخ هذا الريبو وتشغيل yarn في الدليل.

| نظام التشغيل | متوسط ​​الوقت | تطبيع |
| --------------------------------------------- | --- ------- | ------------ |
| لينكس منت | 5.5980 | 1.00000 |
| Windows 10 (بدون مدافع) | 16.5450 | 2.95552 |
| Windows 10 (بدون فهرسة) | 38.5170 | 6.88049 |
| Windows 10 (بدون مدافع ، بدون فهرسة) | 16.8490 | 3.00982 |
| Windows 10 Clean (بدون مدافع ، بدون فهرسة) | 30.7730 | 5.49714 |

مسودة بيانات

قيم Linux Mint مأخوذة من الاختبارات السابقة .

Windows 10 Copy-Item

[7053.7702, 7163.6924, 7081.5366, 7131.2731, 6887.5165, 6960.7251, 6999.6528, 7051.1932, 7046.8592, 7065.1741]

Windows 10 Robocopy

[10096.4991, 10290.1073, 10350.6061, 9999.0552, 10294.0660, 10024.2568, 9949.6786, 9878.1346, 9801.2121, 10264.7418]

Windows 10 Yarn

[16.81, 16.23, 16.29, 16.48, 19.03, 16.27, 17.64, 16.64, 16.05, 17.05]

Windows 10 Yarn Clean

[47.46, 27.83, 28.31, 27.87, 28.90, 30.70, 31.17, 27.97, 28.77, 28.75]

Windows 10 تم تعطيل فهرسة الغزل

[38.47, 38.63, 38.37, 38.82, 38.05, 38.54, 38.44, 37.90, 39.02, 38.93]

ويندوز 10 نسخ الفهرسة معطل

[10222.4855, 10063.3654, 10152.2953, 10151.6155, 10316.7628, 10705.8277, 10199.5391, 10624.1961, 10308.2336, 10326.4731]

Windows 10 Yarn Windows Defender Disabled

[17.03, 16.21, 16.76, 16.43, 16.19, 16.71, 16.23, 16.30, 17.37, 16.22]

Windows 10 Copy Windows Defender Disabled

[7273.9684, 7427.1726, 7409.7312, 7417.4478, 7164.8717, 7427.4655, 7321.0481, 7292.2561, 7159.4540, 7120.8913]

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

keawade شكرًا @ bestander يمكن أن يكون ذلك منذأمي لا تواجه npm هذه المشكلات نفسها أثناء النسخ (المسح الدائم) ، فربما لم يتم توقيع الغزل؟ قد يكون أن windows defender لا يثق في الغزل بنفس مستوى npm. مجرد فكرة...

kumarharsh ، سنحتاج إلى قياس الفرق بين npm والغزل بعد ذلك.
ربما تقوم npm بنسخ ملفات أقل (لم يتم تحسين رفع Yarn لأصغر شجرة للوحدات node_modules).
وسيكون من الرائع لو تمكنا تلقائيًا من إضافة خيوط الغزل إلى القائمة البيضاء عبر المثبت.

ربما لم يتم توقيع الغزل؟ قد يكون أن windows defender لا يثق في الغزل بنفس مستوى npm.

لا أعتقد أنه يمكن توقيع البرامج النصية (باستثناء البرامج النصية PowerShell التي تدعم توقيعات رموز المصادقة) ، لذلك لا أعتقد أن Yarn و npm قد يختلفان في هذا الصدد. مثبت Yarn هو رمز المصادقة موقّعًا تمامًا مثل npm.

وسيكون من الرائع لو تمكنا تلقائيًا من إضافة خيوط الغزل إلى القائمة البيضاء عبر المثبت.

أشعر أن لمس القائمة البيضاء لفحص الفيروسات تلقائيًا سيؤدي إلى وجود أدوات فحص للفيروسات تضع علامة على برنامج التثبيت كبرنامج ضار. يبدو أنه عمل محفوف بالمخاطر. ربما يمكننا تلقائيًا إدراج الدليل في فهرس البحث في القائمة السوداء.

keawade لقد اختبرت robocopy بالخيارات /E /MT (نسخ متعددة الخيوط).

| طريقة النسخ | متوسط ​​الوقت |
| ---------------------- | ---------- |
| نسخ العنصر -Recurse | 20219 |
| Robocopy /E | 26652 |
| Robocopy /E /MT | 9043 |

البيانات الأولية (Windows 10)

نسخ العنصر -Recurse

[19494.3827, 19471.0148, 19573.9441, 19896.9619, 19413.0355, 20050.4264, 19370.4315, 22959.5867, 20969.9693, 20994.3076]

Robocopy /E

[26522.4862, 26489.6131, 26654.8518, 26910.1073, 26536.042, 26836.0344, 26682.3544, 26408.4497, 26883.7998, 26605.5189]

Robocopy /E /MT

[9274.1374, 9125.6525, 9292.1629, 9014.8979, 8947.7882, 8985.4369, 8742.3616, 8915.4609, 8938.8326, 9200.9616]

لا أعتقد أنه يمكن توقيع البرامج النصية (باستثناء البرامج النصية PowerShell التي تدعم توقيعات رموز المصادقة) ، لذلك لا أعتقد أن Yarn و npm قد يختلفان في هذا الصدد. مثبت Yarn هو رمز المصادقة موقّعًا تمامًا مثل npm.

يبدو معقولا.
هل يمكننا مضاعفة هذا؟
في حالة تشغيل npm install هل يظهر المفهرس والمدافع في إدارة المهام؟

اختبارات NPM Defender والفهرسة

لقد سجلت الوقت الذي استغرقته لتشغيل npm install على هذا الريبو في ظل نفس مجموعة الشروط مثل اختبارات الفهرسة والمدافع لطرق نسخ Yarn و Windows.

| نظام التشغيل | متوسط ​​الوقت | تطبيع |
| --------------------------------------------- | --- ------- | ------------ |
| لينكس منت (غزل) | 5.5980 | 1.00000 |
| Linux Mint (NPM) | 28.9793 | 5.17672 |
| Windows 10 (بدون مدافع) | 42.6296 | 7.61514 |
| Windows 10 (بدون فهرسة) | 53.8791 | 9.62470 |
| Windows 10 (بدون مدافع ، بدون فهرسة) | 37.9727 | 6.78326 |
| Windows 10 (بدون تعديلات) | 58.5047 | 10.45100 |

ملخص

يبدو أن NPM يتأثر أيضًا بـ Windows Defender.

مسودة بيانات

NPM (Linux Mint)

[29.2353468, 35.6938315, 31.2105951, 30.9298704, 36.5016868, 31.8017671, 30.6387978, 32.3466556, 31.4340427]

NPM (Windows)

[61.2370640, 63.8799427, 62.3602369, 54.0541606, 55.1055082, 59.8259424, 56.7668692, 61.1153600, 54.7739699, 55.9277175]

NPM مع تعطيل Windows Defender

[41.1666621, 45.6951565, 43.1979249, 43.9185817, 40.8516877, 42.3445648, 43.5419790, 43.5084263, 45.0731120, 36.9975436]

NPM مع تعطيل فهرسة Windows

[61.1470203, 58.6288137, 52.2553500, 52.4279906, 53.5446943, 54.2839412, 51.1620714, 52.1045756, 51.6424888, 51.5937462]

NPM مع Windows Defender وتعطيل فهرسة Windows

[37.1311942, 37.7022530, 38.4630113, 37.5750357, 38.1434941, 37.2711589, 37.2249454, 39.4748951, 38.5522905, 38.1883537]

أفترض أننا سنحتاج إلى التغلب على قيود Windows التي تكون أبطأ في القرص IO عن طريق تقليل عدد عمليات الإدخال / الإخراج بشكل عام وتثقيف الأشخاص حول الفهرسة والمدافع.
يبدو استبدال النسخة بـ robocopy فكرة جيدة أيضًا.

تقليل عدد عمليات الإدخال والإخراج بشكل عام

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

نتطلع إلى علاقات عامة لاستبدال fs streams piping بنسخة robocopy على Windows هنا .

-- تحديث
ومع ذلك ، قد لا يكون هذا هو الأمثل لأن copyBulk لديه بعض المنطق الإضافي مثل الاستثناءات التي قد لا تتم ترجمتها إلى أمر robocopy واحد.

هل يعرف أحد لماذا يحدث هذا لي (في كل مرة)؟

للتوسع في المنشور:
على جهاز Windows الخاص بي - كل yarn add أو yarn rm يعيد نسخ جميع وحدات العقدة في مشروعي ، مما يجعل كل تغيير في package.json يستغرق وقتًا طويلاً للغاية حتى يكتمل. يأتي شريط التقدم هذا لـ 160 ألفًا في كل مرة ، وهو يزحف مثل سلحفاة تقطعت بهم السبل في حقل نفط. انتبه إلى توقيت العملية yarn rm paper التي قمت بها قبل yarn add - 1000 ثانية!

وإلغاء إحدى هذه العمليات add/rm غير ممكن ، لأنه يفسد مجلد node_modules ولن يقوم أي yarn install / npm install بتثبيت جميع التبعيات - وهذا يعني في النهاية أن ينتهي بي الأمر بعمل rm -r node_modules/ والبدء من جديد. هذا السبب الوحيد مؤلم بما يكفي لمنعني من استخدام تثبيت الغزل على الإطلاق.

أعتقد أن لديك وحدات عقدة مرفوعة بشكل سيئ ، سيتم إصلاح هذا الخطأ في # 2676

مع إدخالbestander للرابط الثابت في # 2620 (والذي يعمل بشكل جيد في Windows 7 بدون امتيازات المسؤول) ، انخفض إجمالي أوقات التثبيت الخاصة بي ، وحجم node_modules/ .

بدون ربط:

Done in 167.76s.

real    2m49.633s
user    0m0.229s
sys     0m1.368s

du -sh node_modules/
216M    node_modules/

مع الربط:

Done in 58.07s.

real    0m59.967s
user    0m0.183s
sys     0m1.369s

du -sh node_modules/
189M    node_modules/

انتظر 0.21.1 ، سيكون لديها إصلاح @ kittens للرفع .
يجب أن يكون أسرع

يوم الأربعاء ، 15 فبراير 2017 الساعة 20:04 ، كتب Hutson Betts [email protected] :

مع bestander https://github.com/bestander مقدمة من
hardlinking في # 2620 https://github.com/yarnpkg/yarn/pull/2620 (الذي
يعمل بشكل جيد في Windows 7 دون امتيازات المسؤول) ، بشكل عام
مرات التثبيت ، و node_modules / الحجم ، انخفض.

بدون ربط:

حرر في 167.76 ثانية.

2 م 49.633 ثانية
المستخدم 0m0.229s
0 م 1.368 ثانية

du -sh node_modules /
216M عقدة_موديولات /

مع الربط:

حرر في ٥٨/٠٧.

0m59.967s حقيقي
المستخدم 0m0.183s
0 م 1.369 ث

du -sh node_modules /
189 م node_modules /

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/yarnpkg/yarn/issues/990#issuecomment-280122923 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe-auth/ACBdWAEghXfPo4bX9mN0hV8l8YaH2rmlks5rc1pigaJpZM4KVwpA
.

أنا على Win7 / w Yarn v0.21.3

[3/4] Linking dependencies...
Done in 947.71s. 

اضطررت إلى الانتظار هذا القدر من الوقت لإضافة أي حزمة جديدة بـ yarn add ...
إيقاف المدافع
الفهرسة معطلة

قم بتشغيل بعض AV الأخرى ، لذا اتبع هذه الخطوات كما هو مذكور أعلاه بواسطة Altiano

إدراج مجلد المشروع في القائمة البيضاء من AV
Whiteilst دليل ذاكرة التخزين المؤقت للغزل ((٪ LocalAppData٪ Yarn)) من AV

سيتم التحديث في هذا واحد

kuncevic ، ما هو وقت التثبيت النظيف للمشروع؟
ما هو حجم مجلد node_modules في الملفات؟
كيف تقارن بتثبيت npm؟

@ bestander هذه هي نفس المشكلة معي. أي yarn add أو yarn remove يستغرق وقتًا متساويًا - تقريبًا ، حتى بعد إصلاحات الرفع الخاصة بـ @ kittens .

في كل مرة يحدث هذا:

1. أولاً ، يتم تشغيل Fetching packages (يستغرق حوالي 30 ثانية):
   
2. بعد ذلك ، يتوقف ربط التبعيات مؤقتًا لمدة دقيقة أو دقيقتين.
   
3. بعد ذلك ، يستأنف مع الخطوة التالية ، ويقوم بتثبيت ملفات 63 ألف مرة أخرى.
   

كما قلت ، يحدث هذا في كل مرة أشغل فيها yarn add أو yarn remove . لا يهم ما إذا كانت التبعية التي أقوم بتثبيتها تعتمد على أي تبعية أخرى ، يستغرق الأمر البسيط npm install لتثبيت تبعية جديدة أو ترقية تبعية موجودة جزءًا صغيرًا من هذا الوقت. لقد تحسنت الأمور بمقدار 2x مع إصلاحات الرفع @ kittens ، ولكن لا يزال الوقت المستغرق كثيرًا.

@ bestander إذا كنت تريد حالة https://github.com/kumarharsh/yarn-bug ، وتشغيل yarn install ، ثم yarn add react-helmet .

يحافظ الغزل على الحتمية في كل مرة يتم فيها تشغيل الإضافة / الإزالة ، لذلك يحتاج إلى التحقق مما إذا كانت أي تبعية قد تم رفعها إلى جذر node_modules عند تغيير التبعيات.
هذا هو السبب في أنه يدير مرحلة ربط كاملة.

جلب التبعيات - التنزيل ، لا يمكنك تحسينها.
مرحلة الربط الأولى (1561 عملية) - تقوم بإنشاء جميع المجلدات لجميع التبعيات.
مرحلة الارتباط الثانية (عمليات 63 كيلو بايت) - تقوم بنسخ الملفات من ذاكرة التخزين المؤقت إلى node_modues.

يحسن الغزل عمليات نسخ الملفات عن طريق التحقق مما إذا كانت الملفات هي نفسها قبل القيام بالنسخ.
قد نرغب في تحديد ملف تعريف هذه المنطقة بشكل أفضل ومعرفة ما إذا كان بإمكاننا تقليل عدد عمليات الإدخال / الإخراج غير الضرورية.
ربما على نسخ Windows سيكون أسرع من التحقق؟

ماذا عن npm ، ما مدى سرعة التثبيت النظيف؟

يتطلب التثبيت النظيف لـ npm ( npm install ) 552301.1944ms .
يتطلب تثبيت تبعية إضافية ( npm install weird ) 57023.7593ms . (يتم إهدار معظم هذا الوقت في paperjs في محاولة لتثبيت لوحة قماشية باعتبارها وحدة تخزين - ولكن هذه المرة ستكون شائعة لكل من npm والغزل)

يتطلب التثبيت النظيف للغزل ( yarn install ) 612698.4915ms .
يتطلب تثبيت تبعية إضافية ( yarn add weird ) 495633.0307ms .

npm version 3.10.9
yarn version 0.21.3

bestanderkumarharsh غزل لا يحسن عمليات نسخ الملفات على ويندوز بسبب libuv / nodejs علة (انظر رقم 2958 لإصلاح محتمل في التعليمات البرمجية غزل) غير موجودة على عقدة 7.1+ حتى تتمكن من الحصول الأمر الثاني الخاص بك ( yarn add ) لتكون أسرع كثيرًا بمجرد ترقية العقدة.

يعد استخدام عملية نسخ ملفات Windows أسرع قليلاً من استخدام واجهة برمجة تطبيقات العقدة لنسخ الملفات أيضًا (انظر # 2960 للحصول على علاقات عامة محتملة) وستعمل على تحسين yarn install قليلاً ولكني لا أعرف ما إذا كان سيتوافق مع npm (لم تختبر)

تم التحديث للتو إلى 7.8.0

nvm install 7.8.0
npm install npm -g (came with 4.4.4)
nvm use 7.8.0
`git clone https://github.com/angular/material2`
cd material2
yarn install - Done in 210.22s.
rimraf node_modules
yarn install - Done in 180.66s.
rimraf node_modules
yarn install - Done in 181.11s.

ومع ذلك ، من خلال القيام بـ yarn add rimraf ، تم إنجازه في 20.52s. ولكن لماذا yarn install بعد إزالة node_modules استغرق وقتًا طويلاً؟

ملاحظة

rimraf node_modules
npm install - Done in 332.4s
rimraf node_modules
npm install - Done in 402s
rimraf node_modules
npm install - Done in 489.6s

@ kuncevic جميل أن ترى أن ترقية العقدة تعمل مقابل yarn add :)

فيما يتعلق node_modules الفارغ ، فإن الشيء الجيد الذي يجب القيام به هو قياس المبلغ المستحق للغزل والمبلغ المستحق لنظام الملفات ، والقرص الصلب ، ومكافحة الفيروسات.
ما فعلته لاختبار ذلك هو نسخ node_module (كما تم إنشاؤه بواسطة الغزل ، وليس npm) من material2 في مكان ما في ذاكرة التخزين المؤقت للغزل:

for /f "delims=" %i in ('yarn cache dir') do set yarncachedir=%i
xcopy /E /Y /I /Q node_modules %yarncachedir%\x-temp

ثم لكل اختبار قمت بتنظيف node_modules وقمت بتشغيل إما yarn install أو npm install أو xcopy من المجلد الذي تم إنشاؤه مسبقًا:

rd node_modules /s /q
powershell -Command "Measure-Command { xcopy /E /Y /I /Q %yarncachedir%\x-temp node_modules}"

واستغرق مجموع الثواني.

النتائج

فيما يلي النتائج على 3 أجهزة كمبيوتر

• 🏠 كمبيوتر منزلي: Samsung 950 Pro NVMe و ESET Nod32
• 🏢 كمبيوتر العمل: Samsung 850 EVO SATA و TrendMicro OfficeScan الذي لا يمكنني تعطيله
• 🍎 MacBook pro: إصدار 2015 ، على macos ، لا يوجد مضاد فيروسات

|| yarn 🏠 | npm 🏠 | xcopy 🏠 | yarn 🏢 | npm 🏢 | xcopy 🏢 | yarn 🍎 | npm 🍎
| - | - | - | - | - | - | - | - | -
| تعطيل AV | 34 ثانية | التسعينيات | 23 ثانية | - | - | - | 32 ثانية | 92 ثانية
| AV استبعاد ذاكرة التخزين المؤقت والتعليمات البرمجية | 38s | 104 ثانية | 29
| Av يستبعد ذاكرة التخزين المؤقت فقط | 43 ثانية | - | 31 ثانية | - | - | - | - | -
| Av كامل | 48s | 122 ثانية | 32 100 ثانية | 274 ثانية | 236s | - | -

في كل مرة يتم فيها تمكين AV ، كان يتصدر مخطط وحدة المعالجة المركزية خلال yarn install أو xcopy (تم أخذ 30٪ من إجمالي وحدة المعالجة المركزية على جهاز الكمبيوتر المنزلي الخاص بي كحد أقصى ولكن على جهاز الكمبيوتر الخاص بالعمل ، تملأ نواة واحدة لـ xcopy & كل ما عندي من النوى للغزل)
xcopy أبطأ على جهاز الكمبيوتر الخاص بي في العمل من الغزل ، وأظن أنه لا ينسخ الملفات بالتوازي بينما يقوم الغزل (لا ينبغي أن يكون ذلك مهمًا لعمليات IO المرتبطة ولكن AV تجعلها عملية مرتبطة بوحدة المعالجة المركزية ولم تتم كتابة xcopy إليها محاربة الكثير من الغباء 😄)

فى الختام

• yarn أسرع من npm ويمكن أن يكون أسرع من xcopy عندما تجعل AV نسخة الملف من وحدة المعالجة المركزية
• Windows على SSD جيد ليس أبطأ حقًا من MacBook Pro 2015 (يحتوي بالفعل على SSD جيد) حتى لو كان من الصعب المقارنة لأنه لم يتم تثبيت نفس الحزم بالضبط ، وليس كل البرامج النصية بعد التثبيت تفعل الشيء نفسه
• يمكن إجراء بعض التغييرات في الغزل لتفادي ذلك (ملفات الارتباط الرمزي؟) ولكن التعامل مع الكثير من الملفات الصغيرة يكون بطيئًا بشكل أساسي
• على windows AV يمكن أن يجعله أبطأ ، أضيف 30 ٪ عند التمكين في كل من مجلدات المصدر والمجلد 😞
• يمكن أن تكون مركبات AV الخاصة بالشركات

ستكون إضافة npm ومجلدات ذاكرة التخزين المؤقت و node.exe إلى قائمة استبعاد المدافع كافية ، بالطبع لا يمكن أن يكون كل هذا في مجلدات مفهرسة. الآن تستغرق إضافة الغزل / rm 7 ثوانٍ

شكرًا للجميع ، وصل تحسين كبير لنظام التشغيل Windows إلى 0.24 https://github.com/yarnpkg/yarn/pull/3234#issuecomment -297552326

vbfox هل يمكنك إضافة أرقام الإصدارات لـ npm و yarn في مقياس الأداء؟

هذا لا يزال قطعة من الهراء لنظام MacOSX

ما زلت أعاني من بعض أوقات التثبيت المجنونة. يبدو أن yarn add بتثبيت وربط كل شيء (كل العناصر في package.json ، حوالي 30 ألف تبعيات) طوال الوقت.

إصدارات Linux:

$ yarn -v
1.3.2
$ node -v
v8.9.3

إصدارات Windows:

> conemu-cyg-64.exe --version
ConEmu cygwin/msys connector version 1.2.2
> wslbridge.exe --version
wslbridge 0.2.3
> Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' | Select-Object ProductName, CurrentMajorVersionNumber, CurrentMinorVersionNumber, ReleaseId, CurrentBuild, CurrentBuildNumber, BuildLabEx


ProductName               : Windows 10 Pro Insider Preview
CurrentMajorVersionNumber : 10
CurrentMinorVersionNumber : 0
ReleaseId                 : 1709
CurrentBuild              : 17025
CurrentBuildNumber        : 17025
BuildLabEx                : 17025.1000.amd64fre.rs_prerelease.171020-1626

لدي سؤالان (ونصف):

1. ما هو الحل المقبول للقضية في هذا الموضوع؟ هل كان # 3234 أم تعديل Windows Defender؟

   • إذا كان الحل هو تعديل Windows Defender ، فهل هناك كتابة كاملة لما يجب القيام به في مكان ما؟

2. هل مشكلتي متعلقة فعلاً بهذا الموضوع ، أم يجب علي إنشاء واحدة جديدة؟

شكرًا لإثارة مشكلة جديدة ، سأرد هناك

لقد مر ما يقرب من ساعة الآن وأنا في انتظار هذا الأمر لإنهاء العملية. لقد اتبعت النقاط المذكورة أعلاه التي ذكرتها Altiano ولكن لا شيء يعمل

هل لدينا بديل لهذا؟ مثل هل يمكنني استخدام npm i -g . سيعمل بنفس الطريقة أم سأضطر إلى إجراء بعض التغييرات لأن هذا الرمز يستخدم الغزل workspace

لذلك أخيرًا بعد الكفاح لمدة 2-3 ساعات ، اضطررت إلى استخدام npm i -g . بدلاً من yarn global add file:. . عملت npm مثل السحر