Yarn: Butuh pengoptimalan besar untuk Windows

+1

Hai @OshotOkill! Terima kasih telah mencoba Yarn. Apakah Anda menggunakan Cygwin atau WSL ("Bash di Ubuntu pada Windows")? Keduanya diketahui memiliki kinerja IO disk yang cukup buruk.

Selain itu, React Native memiliki banyak sekali file sehingga menyalinnya ke node_modules cukup lambat, dan IO disk untuk banyak file kecil di Windows umumnya lebih lambat daripada Mac OS (yang lebih lambat dari Linux ext4). Kami memiliki tugas untuk bereksperimen dengan tautan keras (# 499) yang seharusnya meningkatkan kinerja dalam skenario ini.

Tidak ada cache & lingkungan jaringan yang sama

Perbaikan utama dengan Yarn adalah ketika Anda memiliki cache yang hangat (yaitu setelah Anda menginstal paket setidaknya sekali), tetapi dengan React Native, sejumlah besar file juga akan menjadi penyebab dari beberapa kelambatan.

@ Daniel15 Tidak, saya tidak menggunakan Cygwin / MinGW / MSYS2 atau WSL (yang terakhir gagal karena bug yang rumit).

Menurut uraian Anda, saya dapat berasumsi bahwa masalahnya disebabkan oleh sistem file (NTFS) kan? Bahkan jika cache hangat ada, proses penyalinan masih berjalan lebih lambat daripada MacOS.

Semoga tim pengembang dapat memberikan solusi secepatnya. Terima kasih.

Saya melihat hal yang sama.

Lakukan instal, hapus node_modules, instal

MacBookPro membutuhkan waktu 17 detik, mesin Windows saya membutuhkan 122 detik.

Seseorang menunjukkan ini mungkin terkait dengan perangkat lunak anti-virus yang memindai node_modules dan cache benang global secara terus menerus. Bisakah Anda mencoba menonaktifkannya untuk folder itu?

@cpojer Saya kira mereka benar. Saya tidak memiliki perangkat lunak anti-virus di mesin saya kecuali Windows Defender yang sudah diinstal sebelumnya, jadi saya melarang pemindaian folder cache global & folder proyek saya dan melakukan beberapa tes:

Default: 128.08s

Tidak ada pemindaian folder cache: 104.43s

Tidak ada pemindaian folder proyek: 78.28s

Tidak ada pemindaian folder cache & folder proyek: 53.48s

Meskipun lebih lambat dari Mac selama 10+ detik, ini memiliki peningkatan yang signifikan.

Ini harus diinformasikan dari dokumen resmi saya kira.

Seseorang menunjukkan ini mungkin terkait dengan perangkat lunak anti-virus yang memindai node_modules dan cache benang global secara terus menerus.

Tangkapan yang bagus! Saya benar-benar lupa tentang ini karena saya sudah memiliki c:\src daftar putih di komputer saya.

@OshotOkill - Apakah Anda ingin mengirimkan permintaan penarikan untuk menambahkan catatan tentang aplikasi antivirus ke situs web, dalam petunjuk penginstalan Windows? Berikut file yang perlu Anda edit: https://github.com/yarnpkg/website/blob/master/en/docs/_installations/windows.md (Anda dapat mengeditnya langsung di Github). Itu akan dihargai 😄

Saya tidak begitu teliti seperti @OshotOkill , tetapi saya menambahkan pengecualian untuk source saya dan folder instal node saya, dan kemudian secara khusus mengecualikan binari benang, npm dan node dan sekarang waktu instal baru saya di Windows turun menjadi 50 detik dari 122 detik .

@ Daniel15 PR siap. Minta maaf atas bahasa Inggris saya yang buruk.

PR telah digabungkan. Tutup masalah ini.

Ini masih sangat lambat di windows, bahkan menonaktifkan anti-virus dan Windows defender. Saya tidak berpikir itu hanya masalah lingkungan (seperti solusi anti-virus ini) tetapi sepertinya benang mencoba menyalin semua file, 1-oleh-1 bahkan jika Anda menginstal beberapa ketergantungan yang tidak terkait.

Mengapa tidak hanya menghapus / menyalin file yang perlu diubah? Jika saya telah menginstal webpack dan tidak diubah ketika saya menginstal rimraf , Seharusnya tidak harus disalin lagi dari cache ke folder node_modules lokal.

Saya telah membuat artikel StackOverflow tentang ini juga: http://stackoverflow.com/questions/40566222/yarn-5x-slower-on-windows

Ngomong-ngomong, dalam benchmark Ubuntu saya (dual-boot), saya menggunakan drive NTFS yang sama dengan yang biasanya dijalankan oleh Windows; dan masih cepat di sana.

Menambahkan node.exe ke pengecualian Windows Defender memberi saya peningkatan kinerja yang luar biasa http://126kr.com/article/1884rsed7l

Saya pasti akan mencobanya!

Itu tampaknya meningkatkan kecepatan sedikit 212 -> 170 detik
Jadi sepertinya membantu, tetapi masih bisa ditingkatkan, karena masih lebih dari 3x lebih lambat daripada di Linux

Masalah lain yang saya perhatikan - Layanan pengindeksan pada Windows mencoba mengindeks setiap file di node_modules.
Saya tidak terlalu membutuhkannya sama sekali, jadi saya menonaktifkannya http://www.softwareok.com/?seite=faq-Windows-10&faq=53 dan mendapatkan peningkatan kinerja lainnya.

Jendela saya tidak diatur untuk mengindeks jalur yang dimaksud, jadi itu masih belum menyelesaikan masalah.

Jadi untuk menyimpulkan ada 4 cara untuk meningkatkan kinerja:

• Masukkan folder proyek ke daftar putih dari AV
• Memutuskan direktori cache Yarn ((% LocalAppData% Yarn)) dari AV
• Menambahkan node.exe ke pengecualian Windows Defender
• Menonaktifkan layanan Pengindeksan di Windows pada folder node_modules

@Altiano ya, tetapi itu masih belum cukup untuk mendapatkan kinerja bahkan mendekati Mac / Linux

Tampaknya agak samar bahwa Anda harus menonaktifkan AV atau pengindeksan pada direktori untuk membuat benang secepat atau lebih cepat dari npm. Lagi pula, Anda tidak perlu melakukan ini untuk npm. Saya memutuskan untuk mencoba benang karena dinyatakan cepat dan pemasangan offline membuat pengkodean tanpa koneksi jaringan menjadi hal yang masuk akal. Apakah tidak ada cara untuk mengoptimalkan penautan?

Menurut beberapa masalah yang terkait di sini dan komentar di atas, saya ingin membuka kembali masalah ini untuk mengumpulkan beberapa solusi lain.

Secara pribadi saya menyarankan untuk membuat daftar konfigurasi perangkat keras tentang mesin uji Anda dan mengunggah beberapa foto terkait. Mungkin ada banyak elemen tidak relevan lainnya yang membuat perbedaan besar antara platform daripada Yarn itu sendiri, yaitu kinerja benchmark dari SSD pada MacBook biasanya jauh lebih baik daripada mesin Windows.

@OshotOkill seperti yang saya katakan sebelumnya, saya mendapatkan kinerja 3,5x lebih lambat pada Windows vs Linux dengan indeks dan pembela jendela dinonaktifkan untuk direktori yang relevan, pada PC biasa yang sama pada drive _ntfs_ yang sama. Bahwa bahkan di ntfs itu jauh lebih cepat di Linux mengatakan banyak hal yang saya pikirkan.

Mari kita bahas alasannya.
Mungkinkah NTFS bekerja lebih lambat pada sejumlah besar file yang dipindahkan selama penginstalan?

Adakah yang bisa berbagi cara untuk merepro ini di satu mesin?
Misalnya, package.json tertentu yang diinstal pada laptop Windows membutuhkan waktu X detik tetapi berjalan di VirtualBox Ubuntu X-20% detik.

@amcsi @bestander Seperti yang sering terjadi, EXT4 / XFS lebih cepat saat menyalin file kecil dalam jumlah besar. Namun, NTFS tidak jauh lebih lambat. Saya baru saja membersihkan cache dan mengujinya lagi dengan menggunakan versi terbaru Yarn and Node (0.19.1 & 7.5.0):

Hasilnya sangat mirip dengan MacBook saat menginstal react-native . Yang saya lakukan hanyalah memasukkan folder terkait dan proses Node.exe ke daftar putih.

Saya mengalami masalah ini sendiri sampai saya memasukkan proses node.exe dan yarn.exe ke dalam daftar putih di Windows Defender, bersama dengan direktori proyek saya. Saya belum menonaktifkan pengindeksan pencarian sama sekali, juga belum memasukkan direktori cache Yarn ke daftar putih. Waktu penginstalan berubah dari 190+ detik pada proyek berukuran sedang menjadi sekitar 25 detik dari cache yang bersih. Mesin Ubuntu saya hanya sedikit lebih cepat dari itu, tetapi hanya 5-10 detik.

Konfigurasi perangkat keras:
SSD 512 GB
RAM 12 GB
AMD FX-8350 8-Core CPU @ 4,01ghz
Windows 10 64-bit, build 14986.

Saya baru saja melakukan beberapa tes cepat pada sistem saya sendiri. Saya punya Linux Mint dan Windows 10 dual boot dari SSD yang sama. Saya membersihkan cache benang saya, menghapus node_modules dan menjalankan yarn pada proyek vue ini .

Linux Mint: _12.22s_

Windows 10 (Tanpa daftar putih): _64.32s_

Windows 10 (Dengan daftar putih): _42.58s_

Ini adalah pengecualian Windows Defender yang saya aktifkan:

Sementara daftar putih tampaknya memiliki efek yang signifikan, itu masih tidak mendekati kecepatan di Linux.

EDIT: Untuk @bestander , inilah data saya yang dinormalisasi:

| OS | Perhitungan | Data Normalisasi |
| --- | --- | --- |
| Linux Mint | 12.22 / 12.22 | 1 |
| Windows 10 | 64.32 / 12.22 | 5.2635 |
| Windows 10 (Dengan daftar putih) | 42.58 / 12.22 | 3.4845 |

@keawade Saya memiliki 26.48 detik untuk menginstal proyek Anda dari cache bersih, dan 13.58 detik untuk menginstalnya dengan cache.

Hanya spitballing di sini, saya menggunakan Yarn.cmd dari penginstal MSI dan sepertinya Anda menggunakan Yarn yang diinstal dari NPM. Saya ingin tahu apakah mungkin ada perbedaan di antara mereka?

@nozzlegear Meskipun itu mungkin, saya pikir itu lebih kecil kemungkinannya daripada karena koneksi internet yang berbeda.

Kita perlu menghilangkan jaringan dari ini.
Saat ini saya dapat menguji repo ini pada Windows 10 terbaru dengan mengaktifkan fitur "Linux di Windows".
Baik melalui CMD dan Bash dengan instalasi cache utama membutuhkan waktu sekitar 27-29 detik pada prosesor 2 inti i7.

@keawade , dapatkah Anda menjalankan pengujian yang sama dengan node_modules dihapus tetapi cache di tempatnya?

Saya belum bisa menginstal OS kedua di perangkat yang saya miliki.
Adakah yang bisa memeriksa apakah menjalankan Windows dan Linux dalam kotak Virtual memberikan hasil yang berbeda?

Saya telah membangun master saat ini dengan cap waktu https://github.com/yarnpkg/yarn/releases/download/v0.21.0-pre/yarn-0.21.0-0.js

Dapatkah Anda menggunakannya untuk menginstal dengan --verbose flag?

Misalnya

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

Ini harus memberikan stempel waktu untuk semua operasi FS

Data tanpa membersihkan cache

_Catatan: Data ini sedang direkam pada sistem boot ganda. Semua perangkat keras identik untuk pengujian ini._

| OS | Waktu Rata-rata | Dinormalisasi |
| ----------------------------- | ---------- | -------- ---- |
| Linux Mint | 5.598s | 1.00000 |
| Windows 10 (dengan daftar Putih) | 12.119d | 2.16488 |
| Windows 10 (tanpa daftar putih) | 31,578d | 5.64094 |

_Avg Waktu adalah rata-rata dari 10 tes_

Data Linux Mint Mentah

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

Data Windows 10 mentah

Dengan Daftar Putih

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

Tanpa Daftar Putih

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

Metodologi

Saya menggunakan skrip PowerShell ini untuk menghasilkan semua data yang ditampilkan di sini. Skrip mengkloning repo ini dan menjalankan 10 iterasi dari perintah yarn , menghapus node_modules setelah setiap iterasi.

@bestander , saya telah memperbarui posting sebelumnya dengan data Windows.

Bagus, terima kasih untuk lebih banyak data.
Bisakah Anda mencoba versi --verbose dengan yarn.js dengan cap waktu untuk kedua OS?
Ini akan memberi kita ide bagus di mana waktu dihabiskan.

Wah, itu banyak penebangan! Apakah Anda ingin 10 proses untuk setiap kombinasi OS / daftar putih atau satu untuk setiap kombinasi cukup baik?

@bestander Ini dia! Satu dari masing-masing.

Catatan samping: Ternyata jika Anda mencoba mengunggah ~ 30mb teks mentah ke satu koleksi inti Anda mendapatkan kesalahan nginx 405. 😆

~ Linux Mint ~
~ Windows 10 dengan pengecualian dan dengan bersih ~
~ Windows 10 dengan pengecualian dan tanpa _clean_ ~
~ Windows 10 dengan bersih dan tanpa _exclusions_ ~
~ Windows 10 tanpa _exclusions_ dan _without_ clean ~

VerboseLogs.tar.gz

EDIT: Menghapus intisari dan mengupload file yang dikompresi.

Ternyata jika Anda mencoba mengunggah ~ 30mb teks mentah ke satu koleksi inti Anda mendapatkan kesalahan nginx 405. 😆

Anda dapat mengompres file (bzip2 atau 7-Zip) dan melampirkannya di sini ... Teks biasa terkompresi dengan sangat baik :)

@ Daniel15 Poin yang bagus, berikut adalah file yang dikompresi: VerboseLogs.tar.gz

1 lari akan baik-baik saja :)

Saya membandingkan LinuxMint.txt vs Windows10NoClean.txt

Linux:

• fase menghubungkan dimulai pada 1,156 detik
• semua folder di dalam node_modules dibuat di 1.968
• file terakhir disalin pada 3,873 detik
• pembangunan selesai dalam 3 detik lagi

Windows

• fase menghubungkan dimulai pada 2.779 detik
• semua folder di dalam node_modules dibuat di 4.83
• file terakhir disalin pada 32.853
• pembangunan selesai dalam 3 detik lagi

Jelas pencatatan verbose mempengaruhi waktu eksekusi di Windows (12 -> 35 detik) tetapi tidak di Linux (6 detik yang sama).

Dari benchmark yang saya temukan di internet Linux EXT3 FS biasanya mengungguli NTFS ketika banyak file yang disalin.
Saya bertanya-tanya apakah ini adalah batasan yang harus kita hadapi.

@keawade , apakah kecepatannya berbeda saat menggunakan npm @ 3 di Windows dan Linux?

Beberapa ide:

• Windows mungkin buruk saat menyalin secara bersamaan, kami menyalin file dalam 4 utas. Mungkin melakukannya single threaded?
• Mungkin menggunakan robocopy wrapper di Windows https://github.com/mikeobrien/node-robocopy
• kami menggunakan readstream.pipe.writestream untuk menyalin file, mungkin itu tidak efisien di Windows

Jika Anda ingin bereksperimen, ganti 4 dengan 1 di https://github.com/yarnpkg/yarn/blob/master/src/util/fs.js#L322 dan lihat apakah penyalinan berulir tunggal semakin cepat di windows

Tes Benang

Sesuai permintaan @bestander , saya melakukan fork yarnpkg/yarn dan mengubah baris 322 dari src/util/fs.js , mengganti 4 dengan 1 . Saya kemudian menggunakan yarn run build untuk membangun proyek dan menjalankan 10 pengujian dengan build itu menggunakan yarn.cmd yang dikompilasi oleh build. Inilah hasilnya.

| | Waktu Rata-rata | Dinormalisasi |
| ---------------------------- | ---------- | --------- --- |
| Windows 10 (dengan daftar Putih) | 12.119d | 1.00000 |
| Untaian salinan tunggal | 16,927d | 1.39673 |
| Salinan utas tunggal + Bersihkan | 42.268d | 3.48775 |

_Avg Waktu adalah rata-rata dari 10 tes_

Sepertinya hanya menggunakan satu utas untuk menyalin file menghasilkan waktu pemasangan yang sedikit lebih lambat.

Data mentah

Windows 10 (dengan daftar Putih)

Data ini dari pengujian sebelumnya

Thread Salinan Tunggal

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

Benang Salinan Tunggal + Bersihkan

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

Terima kasih, @keawade.
Dapatkah Anda memverifikasi asumsi saya bahwa NTFS mungkin lebih lambat dalam menyalin file dalam jumlah besar daripada Linux FS?

Ukur penyalinan melalui node_modules yang diinstal penuh terminal ke lokasi lain di Linux Mint dan Windows 10.

Anda juga perlu menguji salinan menggunakan robocopy dengan opsi /mt (salinan multi-utas)

Saya juga ingin melaporkan bug yang mungkin dilaporkan, di mana setiap yarn add atau yarn remove membutuhkan waktu sekitar 30-40 menit. Tampaknya menyalin SEMUA dependensi lagi, dan karena saya menggunakan Windows, ini membutuhkan waktu lama. Lihat masalah terkait:

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

@kumarharsh # 2458 Butuh waktu 28 detik untuk menyelesaikan penginstalan.

Juga saya harus menyebutkan bahwa jangan lupa untuk memasukkan folder proyek ke daftar putih juga, tidak hanya cache.

Salin Tes

Saya menggunakan skrip ini untuk menjalankan 10 iterasi salinan di Linux Mint dan Windows 10. Saya menyalin repo ini setelah menjalankan yarn di direktori. Ini hasil saya.

| OS | Waktu Rata-rata | Dinormalisasi |
| ------------ | ------------ | ------------ |
| Linux Mint | 1527.4620 | 1.00000 |
| Windows 10 | 53676.3155 | 35.14085 |

Perbedaan waktu itu gila. Salinan ini selesai menyalin file dari satu lokasi ke lokasi lain di _sSD yang sama_.

Data mentah

Linux Mint

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

Saya tidak punya waktu sekarang untuk menguji robocopy tetapi saya bisa mendapatkan data itu malam ini setelah bekerja.

Uji Robocopy

Saya menggunakan skrip ini untuk menjalankan 10 iterasi salinan di Linux Mint dan Windows 10. Saya menyalin repo ini setelah menjalankan yarn di direktori. Ini hasil saya.

| OS | Waktu Rata-rata | Dinormalisasi |
| ----------------------- | ------------ | ------------ |
| Linux Mint | 1527.4620 | 1.00000 |
| Windows 10 | 53676.3155 | 35.14085 |
| Windows 10 (Robocopy) | 58089.7457 | 38.03024 |

Robocopy bekerja sedikit lebih buruk daripada salinan biasa.

Data mentah

Nilai Linux Mint dan Windows 10 berasal dari tes sebelumnya

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

@keawade , dapatkah Anda memverifikasi bahwa pengindeksan file dan Pembela tidak mengganggu penyalinan?
Afaik bisa terlibat bahkan untuk perintah cp.

Periksa apa yang aktif di Task Manager saat penyalinan selesai.
Dan mungkin matikan saja layanan tersebut untuk tes

Tes Pengindeksan dan Pembela

Saya melakukan tes dalam kondisi berikut:

• Dengan Windows Defender yang dinonaktifkan
• Dengan layanan Pengindeksan Windows dinonaktifkan
• Dengan _both_ menonaktifkan Windows Defender dan layanan Pengindeksan Windows
• Dengan _both_ menonaktifkan Windows Defender dan layanan Pengindeksan Windows _dan_ membersihkan cache Yarn

Untuk menonaktifkan Windows Defender, saya mematikan Real-time protection bawah panel pengaturan Windows Defender .

Untuk menonaktifkan pengindeksan Windows, saya menghentikan layanan Pencarian Windows di panel kontrol Layanan .

_Catatan: Saat Windows Defender diaktifkan, tidak ada pengecualian yang dicantumkan_

Saya menggunakan skrip ini untuk menjalankan 10 iterasi salinan di Linux Mint dan Windows 10. Saya menyalin repo ini setelah menjalankan yarn di direktori. Ini hasil saya.

Ringkasan

Sepertinya pengindeksan Windows (Layanan pencarian) memang berdampak pada operasi penyalinan dan Yarn, dampak yang lebih besar berasal dari Windows Defender.

Penyalinan

| OS | Waktu Rata-rata | Dinormalisasi |
| -------------------------------------------- | ---- -------- | ------------ |
| Linux Mint | 1527.4620 | 1.00000 |
| Windows 10 (Tanpa pembela) | 7301.4307 | 4.78011 |
| Windows 10 (Tanpa pengindeksan) | 10307.0794 | 6.74787 |
| Windows 10 (Tanpa pembela, tanpa pengindeksan) | 7044.1393 | 4.61166 |
| Windows 10 Robo (Tanpa pembela, tanpa pengindeksan) | 10094.8358 | 6.60889 |

Pengindeksan Menonaktifkan sepenuhnya pengindeksan dan antivirus memberikan dorongan besar pada kinerja saat menyalin file.

Benang

Karena hasil di atas sangat jelas, saya pikir kami mungkin dapat menggunakan data tentang kinerja Yarn dalam kondisi ini juga.

Saya menggunakan skrip ini untuk menjalankan 10 iterasi yarn pada Linux Mint dan Windows 10. Saya mengkloning repo ini dan menjalankan yarn di direktori.

| OS | Waktu Rata-rata | Dinormalisasi |
| --------------------------------------------- | --- ------- | ------------ |
| Linux Mint | 5.5980 | 1.00000 |
| Windows 10 (Tanpa pembela) | 16.5450 | 2.95552 |
| Windows 10 (Tanpa pengindeksan) | 38.5170 | 6.88049 |
| Windows 10 (Tanpa pembela, tanpa pengindeksan) | 16,8490 | 3.00982 |
| Windows 10 Clean (Tanpa pembela, tanpa pengindeksan) | 30,7730 | 5.49714 |

Data mentah

Nilai Linux Mint berasal dari tes sebelumnya .

Item Salinan Windows 10

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

Robocopy Windows 10

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

Benang Windows 10

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

Windows 10 Benang Bersih

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

Pengindeksan Benang Windows 10 Dinonaktifkan

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

Windows 10 Copy Indexing Dinonaktifkan

[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 Dinonaktifkan

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

Windows 10 Salin Windows Defender Dinonaktifkan

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

Itulah penelitian yang solid, @keawade , terima kasih telah membagikan semua datanya.
Data menunjukkan bahwa kinerja sistem file mentah adalah penghambat untuk instalasi benang pada Windows.
Saya tidak yakin apakah Yarn dapat melakukan apa pun di sini kecuali ada beberapa perintah salinan pintar yang bekerja di sekitar batasan tersebut

@keawade terima kasih telah @bestander mungkinkah sejak ituibu npm tidak menghadapi masalah yang sama saat menyalin (pemindaian terus-menerus), mungkin benang tidak ditandatangani? Bisa jadi windows defender tidak mempercayai benang setingkat npm. Hanya pemikiran saja...

@kumarharsh , kita perlu mengukur perbedaan antara npm dan benang kemudian.
Mungkin npm menyalin lebih sedikit file (Pengangkatan benang tidak dioptimalkan untuk pohon node_modules terkecil).
Dan akan sangat bagus jika kami dapat secara otomatis memasukkan benang ke daftar putih melalui penginstal.

mungkin benang tidak ditandatangani? Bisa jadi windows defender tidak mempercayai benang setingkat npm.

Saya tidak berpikir skrip dapat ditandatangani (dengan pengecualian skrip PowerShell yang mendukung tanda tangan Authenticode), jadi saya rasa Yarn dan npm tidak akan berbeda dalam hal itu. Pemasang Yarn adalah Authenticode yang ditandatangani seperti npm.

Dan akan sangat bagus jika kami dapat secara otomatis memasukkan benang ke daftar putih melalui penginstal.

Saya merasa seperti menyentuh daftar putih pemindaian virus secara otomatis akan mengakibatkan pemindai virus menandai penginstal sebagai malware. Sepertinya hal yang berisiko untuk dilakukan. Mungkin kami dapat secara otomatis memasukkan direktori ke dalam daftar hitam di pengindeks pencarian.

@keawade Saya telah menguji robocopy dengan opsi /E /MT (salinan multi-utas).

| Salin metode | Waktu rata-rata |
| ---------------------- | ---------- |
| Salin-Item -Recurse | 20219 |
| Robocopy /E | 26652 |
| Robocopy /E /MT | 9043 |

Data mentah (windows 10)

Salin-Item -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]

Saya tidak berpikir skrip dapat ditandatangani (dengan pengecualian skrip PowerShell yang mendukung tanda tangan Authenticode), jadi saya rasa Yarn dan npm tidak akan berbeda dalam hal itu. Pemasang Yarn adalah Authenticode yang ditandatangani seperti npm.

Kedengarannya masuk akal.
Bisakah kita memeriksa ulang ini?
Jika menjalankan npm install apakah Pengindeks dan Pembela muncul di Pengelola Tugas?

Tes Pembela dan Pengindeksan NPM

Saya mencatat waktu yang diperlukan untuk menjalankan npm install pada repo ini di bawah kondisi yang sama dengan metode pengindeksan dan Pengujian Pembela untuk Benang dan Windows.

| OS | Waktu Rata-rata | Dinormalisasi |
| --------------------------------------------- | --- ------- | ------------ |
| Linux Mint (Benang) | 5.5980 | 1.00000 |
| Linux Mint (NPM) | 28.9793 | 5.17672 |
| Windows 10 (Tanpa pembela) | 42.6296 | 7.61514 |
| Windows 10 (Tanpa pengindeksan) | 53.8791 | 9.62470 |
| Windows 10 (Tanpa pembela, tanpa pengindeksan) | 37,9727 | 6.78326 |
| Windows 10 (Tidak ada perubahan) | 58.5047 | 10.45100 |

Ringkasan

Sepertinya NPM juga terpengaruh oleh Windows Defender.

Data mentah

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 dengan Windows Defender Disabled

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

NPM dengan Pengindeksan Windows Dinonaktifkan

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

NPM dengan Windows Defender dan Windows Indexing Dinonaktifkan

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

Saya kira kita perlu mengatasi batasan Windows yang lebih lambat pada disk IO dengan mengurangi jumlah operasi IO secara umum dan mendidik orang tentang Pengindeksan dan Pembela.
Mengganti salinan dengan robocopy sepertinya juga merupakan ide yang bagus.

mengurangi jumlah operasi IO secara umum

Ini adalah ide yang bagus secara umum, dan akan membantu kinerja di mana-mana. Ini juga bisa sangat bermanfaat bagi orang-orang yang membangun di server dengan hard drive yang lambat.

Menantikan PR untuk mengganti perpipaan fs stream dengan robocopy di Windows di sini .

- Perbarui
Namun, ini mungkin tidak optimal karena copyBulk memiliki beberapa logika tambahan seperti pengecualian yang mungkin tidak diterjemahkan ke dalam satu perintah robocopy.

Adakah yang tahu mengapa ini terjadi pada saya (setiap saat)?

Untuk memperluas postingan:
Di mesin Windows saya - setiap yarn add atau yarn rm menyalin ulang semua modul node dalam proyek saya, yang membuat setiap perubahan pada package.json membutuhkan waktu yang sangat lama untuk diselesaikan. Bilah kemajuan untuk 160k dependensi datang setiap waktu, dan merangkak seperti kura-kura yang terdampar di ladang minyak. Amati pengaturan waktu pada operasi yarn rm paper baru saja saya lakukan sebelum yarn add - 1000 detik!

Dan membatalkan salah satu operasi add/rm itu tidak mungkin, karena itu mengacaukan folder node_modules dan yarn install / npm install tidak akan menginstal semua dependensi - yang pada akhirnya berarti bahwa saya akhirnya menghasilkan rm -r node_modules/ dan mulai dari awal lagi. Alasan tunggal ini cukup menyakitkan untuk menghentikan saya menggunakan pemasangan benang sama sekali.

Saya pikir Anda telah mengangkat node_modules dengan buruk, bug ini akan diperbaiki di # 2676

Dengan pengenalan hardlink @bestander di # 2620 (Yang berfungsi dengan baik di Windows 7 tanpa hak administrator), waktu instalasi saya secara keseluruhan, dan ukuran node_modules/ , turun.

Tanpa hardlinking:

Done in 167.76s.

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

du -sh node_modules/
216M    node_modules/

Dengan tautan keras:

Done in 58.07s.

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

du -sh node_modules/
189M    node_modules/

Tunggu 0.21.1, ini akan membuat @kittens memperbaiki pengangkatan.
Harus lebih cepat

Pada Rabu, 15 Feb 2017 pukul 20:04, Hutson Betts [email protected] menulis:

Dengan pengenalan @bestander https://github.com/bestander tentang
hardlink di # 2620 https://github.com/yarnpkg/yarn/pull/2620 (Yang
berfungsi dengan baik di Windows 7 tanpa hak administrator), secara keseluruhan
waktu instalasi, dan node_modules / size, dihapus.

Tanpa hardlinking:

Selesai dalam 167.76 detik.

nyata 2m49.633s
pengguna 0m0.229s
sys 0m1.368s

du -sh node_modules /
216 juta node_modules /

Dengan tautan keras:

Selesai dalam 58.07 detik.

0m59.967s nyata
pengguna 0m0.183s
sys 0m1.369s

du -sh node_modules /
189M node_modules /

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/yarnpkg/yarn/issues/990#issuecomment-280122923 , atau nonaktifkan
utasnya
https://github.com/notifications/unsubscribe-auth/ACBdWAEghXfPo4bX9mN0hV8l8YaH2rmlks5rc1pigaJpZM4KVwpA
.

Saya menggunakan Win7 / w Yarn v0.21.3

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

Harus menunggu jumlah waktu ini menambahkan paket baru dengan yarn add ...
Bek mati
Pengindeksan dinonaktifkan

Jalankan AV lain, jadi ikuti saja langkah-langkah ini seperti yang disebutkan di atas oleh @Altiano

Masukkan folder proyek ke daftar putih dari AV
Memutuskan direktori cache Yarn ((% LocalAppData% Yarn)) dari AV

Akan memperbarui yang satu ini

@kuncevic , berapa waktu penginstalan yang bersih untuk proyek?
Berapa ukuran folder node_modules dalam file?
Bagaimana cara membandingkannya dengan npm install?

@bestander ini masalah yang sama dengan saya. Setiap yarn add atau yarn remove membutuhkan waktu yang sama - tentang, bahkan setelah perbaikan pengangkatan @kittens .

Setiap kali ini terjadi:

1. Pertama, Fetching packages berjalan (membutuhkan waktu sekitar 30 detik):
   
2. Kemudian, menghubungkan dependensi dijeda selama sekitar 1 atau 2 menit.
   
3. Kemudian, itu melanjutkan dengan langkah berikutnya, dan menginstal (?) 63k file lagi.
   

Seperti yang saya katakan, ini terjadi setiap kali saya menjalankan yarn add atau yarn remove . Tidak masalah jika ketergantungan yang saya pasang bergantung pada ketergantungan lainnya, npm install untuk memasang ketergantungan baru atau memutakhirkan yang sudah ada membutuhkan waktu yang lebih singkat. Segalanya membaik 2x dengan perbaikan pengangkatan @kittens , tetapi tetap saja waktu yang dibutuhkan terlalu banyak.

@bestander jika Anda menginginkan casing yang dapat direproduksi, kloning repo ini: https://github.com/kumarharsh/yarn-bug , dan jalankan yarn install , lalu yarn add react-helmet .

Yarn mempertahankan determinisme setiap kali menjalankan add / remove, jadi ia perlu memeriksa apakah ada dependensi yang diangkat ke root node_modules saat dependensi berubah.
Itulah mengapa ini menjalankan fase penautan penuh.

Mengambil dependensi - unduh, Anda tidak dapat mengoptimalkannya.
Fase penautan pertama (operasi 1561) - ini membuat semua folder untuk semua dependensi.
Fase penautan kedua (operasi 63K) - menyalin file dari cache ke node_modues.

Yarn mengoptimalkan operasi penyalinan file dengan memeriksa apakah file-file itu sama sebelum melakukan penyalinan.
Kami mungkin ingin membuat profil area ini lebih baik dan melihat apakah kami dapat mengurangi jumlah IO yang tidak perlu.
Mungkin di Windows menyalin akan lebih cepat daripada memeriksa?

Bagaimana dengan npm, seberapa cepat instalasinya bersih?

Penginstalan bersih untuk npm ( npm install ) membutuhkan 552301.1944ms .
Menginstal ketergantungan tambahan ( npm install weird ) membutuhkan 57023.7593ms . (Sebagian besar waktu ini terbuang percuma di paperjs mencoba memasang kanvas sebagai dep - tapi kali ini akan umum untuk npm & benang)

Pemasangan bersih untuk benang ( yarn install ) membutuhkan 612698.4915ms .
Menginstal ketergantungan tambahan ( yarn add weird ) membutuhkan 495633.0307ms .

npm version 3.10.9
yarn version 0.21.3

@bestander @kumarharsh Yarn tidak mengoptimalkan operasi penyalinan file di windows karena bug libuv / nodejs (Lihat # 2958 untuk perbaikan potensial dalam kode benang) yang tidak ada di node 7.1+ sehingga Anda bisa mendapatkan perintah kedua ( yarn add ) menjadi lebih cepat hanya dengan mengupgrade node.

Menggunakan operasi penyalinan file windows sedikit lebih cepat daripada menggunakan API node untuk menyalin file juga (Lihat # 2960 untuk PR potensial) dan akan mengoptimalkan yarn install sedikit tetapi saya tidak tahu apakah itu akan sesuai dengan npm (tidak menguji)

Baru saja diperbarui menjadi 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.

Namun dengan melakukan yarn add rimraf menyelesaikannya di 20.52s. tetapi mengapa yarn install setelah menghapus node_modules butuh waktu lama?

ps

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 Senang melihat bahwa node pemutakhiran berfungsi untuk yarn add :)

Mengenai kosong node_modules hal yang baik untuk dilakukan adalah mengukur berapa banyak yang disebabkan oleh benang dan berapa banyak yang disebabkan oleh FileSystem, Hard drive & Anti virus.
Apa yang saya lakukan untuk menguji itu adalah menyalin penuh node_module (Seperti yang dihasilkan oleh benang, bukan npm) dari material2 di suatu tempat di cache benang:

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

Dan kemudian untuk setiap tes saya membersihkan node_modules & menjalankan yarn install , npm install atau xcopy dari folder yang dibuat sebelumnya:

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

Dan mengambil total detik.

Hasil

Berikut hasil pada 3 PC

• 🏠 PC Rumah: Samsung 950 Pro NVMe, ESET Nod32
• 🏢 PC Kerja: Samsung 850 EVO SATA, TrendMicro OfficeScan yang tidak dapat saya nonaktifkan
• 🍎 MacBook pro: versi 2015, di macOS, tidak ada anti virus

|| yarn 🏠 | npm 🏠 | xcopy 🏠 | yarn 🏢 | npm 🏢 | xcopy 🏢 | yarn 🍎 | npm 🍎
| - | - | - | - | - | - | - | - | -
| AV Dinonaktifkan | 34s | 90 d | 23 d | - | - | - | 32 d | 92-an
| AV Kecualikan cache & kode | 38s | 104 d | 29 d | - | - | - | - | -
| Av Hanya mengecualikan cache | 43d | - | 31d | - | - | - | - | -
| Av penuh | 48d | 122 d | 32 d | 100-an | 274 d | 236 | - | -

Setiap kali AV diaktifkan, AV berada di puncak grafik CPU selama yarn install atau xcopy (Di PC rumah saya, total cpu 30% diambil maksimal tetapi pada PC kerja saya itu mengisi satu inti untuk xcopy & semua inti saya untuk benang)
xcopy lebih lambat pada PC kerja saya daripada benang, saya curiga karena itu tidak menyalin file secara paralel sementara benang melakukannya (Itu seharusnya tidak masalah untuk operasi terikat IO tetapi AV membuatnya menjadi operasi terikat CPU & xcopy tidak ditulis ke melawan begitu banyak kebodohan 😄)

Kesimpulannya

• yarn lebih cepat dari npm dan bahkan bisa lebih cepat dari xcopy ketika AV membuat salinan file terikat CPU
• Windows pada SSD yang baik tidak lebih lambat dari MacBook Pro 2015 (Yang sudah memiliki SSD yang bagus) meskipun sulit untuk dibandingkan karena paket yang tidak persis sama dipasang, & tidak semua skrip pasca-pemasangan melakukan hal yang sama
• Beberapa perubahan dapat dilakukan di thread untuk menghindari itu (file symlink?) Tetapi pada dasarnya mengatasi banyak file kecil lambat
• Pada windows AV dapat membuatnya lebih lambat , tambang menambahkan 30% ketika diaktifkan di folder sumber & tujuan 😞
• AV perusahaan bisa menjadi jauh lebih lambat daripada AV rumah & mematikan kinerja yang cukup untuk setiap operasi penyalinan menjadi menyakitkan (ketika itu membuat operasi terikat IO terikat CPU secara alami) 😡

Menambahkan npm, folder cache benang dan node.exe ke daftar pengecualian pembela sudah cukup, tentu saja semua ini tidak bisa berada di folder yang diindeks. Sekarang penambahan benang / rm membutuhkan waktu 7 detik

Terima kasih semuanya, pengoptimalan yang signifikan untuk Windows mendarat di 0,24 https://github.com/yarnpkg/yarn/pull/3234#issuecomment -297552326

@vbfox Bisakah Anda menambahkan nomor versi untuk npm dan yarn dalam tolok ukur Anda?

ini masih omong kosong untuk MacOSX

Saya masih mengalami beberapa kali pemasangan yang gila. yarn add sepertinya menginstal dan menautkan semuanya (semua item dalam package.json , ~ 30k dependensi) sepanjang waktu.

Versi Linux:

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

Versi 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

Saya punya dua (setengah) pertanyaan:

1. Apa solusi yang diterima untuk masalah di utas ini? Apakah itu # 3234 atau mengutak-atik Windows Defender?

   • Jika solusinya adalah mengutak-atik Windows Defender, apakah ada catatan lengkap tentang apa yang harus dilakukan di suatu tempat?

2. Apakah masalah saya sebenarnya terkait dengan utas ini, atau haruskah saya membuat yang baru?

Terima kasih telah mengajukan masalah baru, saya akan menanggapinya di sana

Sudah hampir satu jam sekarang dan saya menunggu perintah ini untuk menyelesaikan prosesnya. Saya telah mengikuti poin di atas yang disebutkan oleh @Altiano tetapi tidak ada yang berhasil

apakah kita punya alternatif untuk ini? seperti dapatkah saya menggunakan npm i -g . apakah akan bertindak dengan cara yang sama atau saya harus membuat beberapa perubahan karena kode ini menggunakan benang workspace

Jadi akhirnya setelah berjuang selama 2-3 jam, saya harus menggunakan npm i -g . bukan yarn global add file:. . npm bekerja seperti pesona