Yarn: Нужна большая оптимизация под Windows

+1

Привет, @OshotOkill! Спасибо, что попробовали Yarn. Вы используете Cygwin или WSL («Bash в 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, поэтому я запретил сканирование папки глобального кеша и папки проекта и провел несколько тестов:

По умолчанию: 128.08 с.

Без сканирования папки кеша: 104,43 с

Не сканировать папку проекта: 78,28 с

Без сканирования папки кеша и папки проекта: 53,48 с

Хотя он медленнее Mac на 10+ с, у него есть значительный прирост.

Я думаю, об этом следует сообщить из официальных документов.

Кто-то указал, что это может быть связано с постоянным сканированием антивирусным программным обеспечением node_modules и глобального кеша пряжи.

Хороший улов! Я совершенно забыл об этом, поскольку у меня уже есть c:\src белом списке на моих компьютерах.

@OshotOkill - Хотите отправить запрос на https://github.com/yarnpkg/website/blob/master/en/docs/_installations/windows.md (вы можете редактировать его прямо на Github). Буду признателен 😄

Я не был таким дотошным, как @OshotOkill , но я добавил исключения для своего источника и папки установки узла, а затем специально исключил двоичные файлы yarn, npm и node, и теперь время моей новой установки в Windows сократилось до 50 секунд с 122 секунд .

@ Daniel15 PR готов. Прошу прощения за мой плохой английский.

PR был объединен. Закройте эту проблему.

Это все еще мучительно медленно работает в Windows, даже если отключить антивирус и защитник Windows. Я не думаю, что это просто проблема среды (например, это антивирусное решение), но похоже, что yarn пытается скопировать все файлы, 1 на 1, даже если вы установите какую-то несвязанную зависимость.

Почему бы просто не удалить / скопировать файлы, которые нужно изменить? Если бы у меня был установлен webpack и он не изменялся при установке rimraf , его не нужно было бы снова копировать из кеша в локальную папку node_modules.

Я тоже написал об этом статью на StackOverflow: http://stackoverflow.com/questions/40566222/yarn-5x-slower-on-windows

Между прочим, в моих тестах Ubuntu (с двойной загрузкой) я использовал тот же диск NTFS, на котором обычно работает Windows; и там все еще быстро.

Добавление node.exe в исключения Защитника Windows дало мне огромный прирост производительности http://126kr.com/article/1884rsed7l

Я обязательно попробую!

Кажется, это немного улучшило скорость 212 -> 170 секунд
Кажется, это помогает, но его все еще можно улучшить, потому что он все еще более чем в 3 раза медленнее, чем в Linux.

Еще одна проблема, которую я заметил, - служба индексирования в Windows пытается проиндексировать каждый файл в node_modules.
Мне это вообще не нужно, поэтому я отключил его http://www.softwareok.com/?seite=faq-Windows-10&faq=53 и получил еще один прирост производительности.

Мои окна не настроены на индексирование рассматриваемого пути, так что это все еще не решает проблему.

Подводя итог, можно выделить 4 способа улучшить производительность:

• Добавить папку проекта в белый список из AV
• Белый каталог кэша пряжи ((% LocalAppData% Yarn)) от AV
• Добавление node.exe в исключения Защитника Windows
• Отключение службы индексирования в Windows в папке node_modules

@Altiano да, но этого все еще недостаточно, чтобы получить производительность даже близко к Mac / Linux

Кажется отрывочным, что вам придется отключить AV или индексацию каталогов, чтобы пряжа была такой же быстрой или быстрее, чем npm. В конце концов, для npm этого делать не нужно. Я решил попробовать пряжу, потому что она утверждала, что она быстрая, а автономные установки сделали кодирование без подключения к сети правдоподобным. Нет возможности оптимизировать линковку?

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

Лично я предлагаю перечислить аппаратные конфигурации вашей тестовой машины и загрузить несколько связанных фотографий. Может быть много других нерелевантных элементов, которые имеют большое значение между платформами, а не сам Yarn, т.е. эталонная производительность SSD на MacBook обычно намного лучше, чем на машине Windows.

@OshotOkill, как я сказал ранее, у меня производительность в 3,5 раза ниже в Windows по сравнению с Linux с отключенными индексами и защитником Windows для соответствующих каталогов на том же обычном ПК на том же диске _ntfs_. Я думаю, что даже на ntfs он намного быстрее на Linux.

Давайте рассмотрим причину этого.
Может ли NTFS работать медленнее на большом количестве файлов, перемещаемых во время установки?

Может ли кто-нибудь поделиться способом воспроизвести это на одной машине?
Например, конкретный package.json, установленный на ноутбуке с Windows, занимает X секунд, но работает в VirtualBox Ubuntu X-20% секунд.

@amcsi @bestander Как это часто бывает, EXT4 / XFS быстрее копируют большие объемы небольших файлов. Однако NTFS не намного медленнее. Я просто очистил кеш и снова протестировал его, используя последнюю версию Yarn and Node (0.19.1 и 7.5.0):

Результат действительно близок к MacBook при установке react-native . Все, что я сделал, это просто внес в белый список связанные папки и процесс Node.exe.

У меня сама была эта проблема, пока я не внес в белый список процессы node.exe и yarn.exe в Защитнике Windows вместе с каталогом моего проекта. Я вообще не отключал поисковую индексацию и не внес в белый список каталог кеша Yarn. Время установки уменьшилось с 190+ секунд в проекте среднего размера до примерно 25 секунд из чистого кеша. Моя машина с Ubuntu немного быстрее, но всего на 5-10 секунд.

Конфигурация оборудования:
512 ГБ SSD
12 ГБ ОЗУ
8-ядерный процессор AMD FX-8350 с частотой 4,01 ГГц
64-разрядная версия Windows 10, сборка 14986.

Я просто провел несколько быстрых тестов на своей собственной системе. У меня Linux Mint и Windows 10 с двойной загрузкой с одного и того же SSD. Я очистил кеш пряжи, удалил node_modules и запустил yarn в этом проекте vue .

Linux Mint: _12.22s_

Windows 10 (без белого списка): _64.32s_

Windows 10 (с белым списком): _42.58s_

Это были активные исключения Защитника Windows:

Хотя белый список действительно имел значительный эффект, он все же не приблизился к скорости в Linux.

РЕДАКТИРОВАТЬ: Для @bestander вот мои нормализованные данные:

| ОС | Расчет | Нормализованные данные |
| --- | --- | --- |
| Linux Mint | 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 с для его установки с кешем.

Я использую Yarn.cmd из установщика MSI, и похоже, что вы используете Yarn, установленную из NPM. Интересно, может быть, между ними есть несоответствие?

@nozzlegear Хотя это возможно, я думаю, что это менее вероятно, чем из-за различий в подключении к Интернету.

Нам нужно исключить из этого сеть.
В настоящее время я могу протестировать это репо на последней версии Windows 10 с включенной функцией «Linux в Windows».
Как через CMD, так и через Bash с первичными кешами установка занимает около 27-29 секунд на 2-ядерном процессоре 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.

Данные без очистки кешей

_Примечание: эти данные записываются в системе с двойной загрузкой. Все оборудование для этих тестов идентично.

| ОС | Среднее время | Нормализованный |
| ----------------------------- | ---------- | -------- ---- |
| Linux Mint | 5.598s | 1.00000 |
| Windows 10 (с белым списком) | 12,119 с | 2.16488 |
| Windows 10 (без белого списка) | 31,578 с | 5.64094 |

_Avg Time - это среднее значение по набору из 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 , я обновил предыдущий пост данными Windows.

Отлично, спасибо за дополнительные данные.
Можете ли вы попробовать версию --verbose с yarn.js с отметками времени для обеих ОС?
Это дало бы нам хорошее представление о том, где проводится время.

Уф, это много регистрации! Вы хотите 10 запусков для каждой комбинации ОС / белый список или достаточно одного запуска для каждого?

@bestander Держи! По одному каждого.

Боковое примечание: оказывается, если вы попытаетесь загрузить ~ 30 МБ необработанного текста в единственную коллекцию сущностей, вы получите ошибку nginx 405. 😆

~ Linux Mint ~
~ Windows 10 с исключениями и с чистым ~
~ Windows 10 с исключениями и без _clean_ ~
~ Windows 10 с чистыми и без _exclusions_ ~
~ Windows 10 без _exclusions_ и _without_ clean ~

VerboseLogs.tar.gz

РЕДАКТИРОВАТЬ: удаление сущностей и загрузка сжатых файлов.

Оказывается, если вы попытаетесь загрузить ~ 30 МБ необработанного текста в единую коллекцию сущностей, вы получите ошибку nginx 405. 😆

Вы можете сжать файлы (bzip2 или 7-Zip) и прикрепить их сюда ... Обычный текст сжимается очень хорошо :)

@ Daniel15 Хороший замечание, вот сжатые файлы: VerboseLogs.tar.gz

1 пробежка подойдет :)

Я сравнил LinuxMint.txt и Windows10NoClean.txt

Linux:

• этап связывания начинается с 1,156 секунды
• все папки внутри node_modules, созданные в 1.968
• последний файл скопирован через 3,873 секунды
• сборки выполняются еще через 3 секунды

Windows

• этап связывания начинается с 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 и посмотрите, однопоточное копирование ускоряется в Windows

Тесты потоков

По запросу @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.268s | 3.48775 |

_Avg Time - это среднее значение по набору из 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 в каталоге. Вот мои результаты.

| ОС | Среднее время | Нормализованный |
| ------------ | ------------ | ------------ |
| Linux Mint | 1527.4620 | 1.00000 |
| Windows 10 | 53676.3155 | 35.14085 |

Эта разница во времени безумная. Эти копии были сделаны путем копирования файлов из одного места в другое на _ том же SSD_.

Необработанные данные

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

У меня сейчас нет времени тестировать robocopy, но я могу получить эти данные сегодня вечером после работы.

Робокопи-тест

Я использовал этот сценарий для запуска 10 итераций копий как в Linux Mint, так и в Windows 10. Я скопировал это репо после запуска yarn в каталоге. Вот мои результаты.

| ОС | Среднее время | Нормализованный |
| ----------------------- | ------------ | ------------ |
| Linux Mint | 1527.4620 | 1.00000 |
| Windows 10 | 53676.3155 | 35.14085 |
| Windows 10 (Robocopy) | 58089.7457 | 38.03024 |

Робокопия работает немного хуже, чем обычная копия.

Необработанные данные

Значения 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 , вы можете убедиться, что индексация файлов и Защитник не мешают копированию?
Afaik это может быть задействовано даже для команды cp.

После завершения копирования проверьте, что активно в диспетчере задач.
И, может быть, просто отключите эти службы для проверки

Индексирование и тесты защитника

Я проводил тесты при следующих условиях:

• С отключенным Защитником Windows
• С отключенной службой индексирования Windows
• С _обо_ отключенными Защитником Windows и службой индексирования Windows
• С _обо_ отключенными Защитником Windows и службой индексирования Windows _и_ очисткой кеша Yarn

Чтобы отключить Защитник Windows, я отключил Real-time protection на панели настроек Защитника Windows .

Чтобы отключить индексацию Windows, я остановил службу поиска Windows на панели управления службами .

_Примечание: когда Защитник Windows был включен, исключений не было_

Я использовал этот сценарий для запуска 10 итераций копий как в Linux Mint, так и в Windows 10. Я скопировал это репо после запуска yarn в каталоге. Вот мои результаты.

Резюме

Похоже, что хотя индексирование Windows (служба поиска) действительно влияет на операции копирования и Yarn, большее влияние оказывает Защитник Windows.

Копирование

| ОС | Среднее время | Нормализованный |
| -------------------------------------------- | ---- -------- | ------------ |
| Linux Mint | 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 в каталоге.

| ОС | Среднее время | Нормализованный |
| --------------------------------------------- | --- ------- | ------------ |
| Linux Mint | 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

[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

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

Чистка пряжи Windows 10

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

Индексирование копирования в Windows 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 отключен

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

Windows 10 Копирование Защитника Windows отключено

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

Это серьезное исследование, @keawade , спасибо за то, что поделились всеми данными.
Данные показывают, что производительность сырой файловой системы является узким местом для установки yarn в Windows.
Я не уверен, что Yarn может что-то здесь сделать, если нет какой-то умной команды копирования, которая работает с ограничением.

@keawade, спасибо, что собрать эти числа! @bestander может быть так, посколькуМама npm не сталкивается с такими же проблемами при копировании (постоянное сканирование), может быть, пряжа не подписана? Может быть, Windows Defender не доверяет пряже того же уровня, что и npm. Просто мысль...

@kumarharsh , тогда нам нужно будет измерить разницу между npm и yarn.
Возможно, npm копирует меньше файлов (подъем Yarn не оптимизирован для самого маленького дерева node_modules).
И было бы здорово, если бы мы могли автоматически добавлять пряжу в белый список через установщик.

может пряжа не подписана? Может быть, Windows Defender не доверяет пряже того же уровня, что и npm.

Я не думаю, что сценарии можно подписывать (за исключением сценариев PowerShell, которые действительно поддерживают подписи Authenticode), поэтому я не думаю, что Yarn и npm будут отличаться в этом отношении. Установщик Yarn подписан Authenticode, как и npm.

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

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

@keawade Я тестировал robocopy с параметрами /E /MT (многопоточные копии).

| Метод копирования | Среднее время |
| ---------------------- | ---------- |
| Копировать элемент -Recurse | 20219 |
| Робокопия /E | 26652 |
| Робокопи /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]

Робокопи /E

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

Робокопи /E /MT

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

Я не думаю, что сценарии можно подписывать (за исключением сценариев PowerShell, которые действительно поддерживают подписи Authenticode), поэтому я не думаю, что Yarn и npm будут отличаться в этом отношении. Установщик Yarn подписан Authenticode, как и npm.

Звучит разумно.
Можем ли мы это дважды проверить?
При запуске npm install Индексатор и Защитник отображаются в диспетчере задач?

NPM Defender и тесты индексации

Я записал время, необходимое для запуска npm install в этом репо при тех же условиях, что и тесты индексирования и защитника для методов копирования Yarn и Windows.

| ОС | Среднее время | Нормализованный |
| --------------------------------------------- | --- ------- | ------------ |
| Linux Mint (Пряжа) | 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.

Необработанные данные

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

[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 и отключенным индексированием Windows

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

Я полагаю, что нам нужно будет обойти ограничение, связанное с медленностью Windows при вводе-выводе на диск, путем уменьшения количества операций ввода-вывода в целом и обучения людей вопросам индексирования и Защитника.
Замена копии на robocopy тоже кажется хорошей идеей.

уменьшение количества операций ввода-вывода в целом

В целом это хорошая идея, которая поможет повысить производительность везде. Это также может быть очень полезно для людей, использующих серверы с медленными жесткими дисками.

С нетерпением жду PR для замены конвейера потоков fs на robocopy в Windows здесь .

-- Обновить
Однако это может быть неоптимальным, потому что copyBulk имеет некоторую дополнительную логику, например исключения, которые нельзя преобразовать в одну команду robocopy.

Кто-нибудь знает, почему это происходит со мной (каждый раз)?

Чтобы развернуть сообщение:
На моей машине с Windows - каждый yarn add или yarn rm повторно копирует все модули узлов в моем проекте, что делает каждое изменение package.json мучительно долгим. Этот индикатор выполнения для 160k зависимостей появляется каждый раз и ползает, как черепаха, застрявшая на нефтяном месторождении. Обратите внимание на тайминги операции yarn rm paper я только что проделал перед yarn add - 1000 секунд!

И отмена одной из этих операций add/rm невозможна, так как это приводит к беспорядку в папке node_modules, и любые последующие yarn install / npm install не устанавливают все зависимости, что в конечном итоге означает что я заканчиваю тем, что делаю rm -r node_modules/ и начинаю все сначала. Эта единственная причина достаточно болезненна, чтобы остановить меня от использования yarn install.

Думаю, у вас плохо подняты 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
жесткая ссылка в # 2620 https://github.com/yarnpkg/yarn/pull/2620 (который
отлично работает в Windows 7 без прав администратора), мой общий
время установки и node_modules / size упали.

Без жесткой ссылки:

Совершено в 167.76с.

реальный 2 мин 49,633 сек
пользователь 0m0.229s
sys 0m1.368s

du -sh node_modules /
216M node_modules /

С жесткой привязкой:

Совершено 58.07.

реальный 0m59.967s
пользователь 0m0.183s
sys 0m1.369s

du -sh node_modules /
189M 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
Белый каталог кэша пряжи ((% LocalAppData% Yarn)) от AV

Буду обновлять по этому поводу

@kuncevic , какое время чистой установки для проекта?
Каков размер папки node_modules в файлах?
Как это сравнить с установкой npm?

@bestander, у меня такая же проблема. Любые yarn add или yarn remove занимают одинаковое время - примерно, даже после исправлений подъема

Каждый раз это происходит:

1. Сначала выполняется Fetching packages (занимает около 30 секунд):
   
2. Затем связывание зависимостей приостанавливается примерно на 1-2 минуты.
   
3. Затем он возобновляется со следующего шага и снова устанавливает (?) 63k файлов.
   

Как я уже сказал, это происходит каждый раз, когда я запускаю yarn add или yarn remove . Не имеет значения, зависит ли устанавливаемая мной зависимость от какой-либо другой зависимости. Простой npm install для установки новой зависимости или обновления существующей занимает лишь часть этого времени. Ситуация улучшилась в 2 раза с исправлениями подъема потрачено слишком много.

@bestander, если вам нужен воспроизводимый случай, https://github.com/kumarharsh/yarn-bug и запустите yarn install , а затем yarn add react-helmet .

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

Получение зависимостей - скачать, оптимизировать нельзя.
Первый этап связывания (1561 операция) - создает все папки для всех зависимостей.
Вторая фаза компоновки (63К операций) - копирует файлы из кеша в node_modues.

Yarn оптимизирует операции копирования файлов, проверяя, совпадают ли файлы перед копированием.
Возможно, мы захотим лучше профилировать эту область и посмотреть, сможем ли мы уменьшить количество ненужных операций ввода-вывода.
Может, на винде копирование было бы быстрее проверки?

А как насчет 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

@bestander @kumarharsh Yarn не оптимизирует операции копирования файлов в Windows из-за ошибки libuv / nodejs (см. # 2958 для потенциального исправления в коде пряжи), которая отсутствует на узле 7.1+, поэтому вы можете получить вторую команду ( yarn add ), чтобы быть намного быстрее, просто обновив узел.

Использование операции копирования файлов Windows немного быстрее, чем использование API узла для копирования файлов (см. # 2960 для потенциального PR), и немного оптимизирует 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 (созданный yarn, а не 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 отключен | 34s | 90-е | 23-е | - | - | - | 32-е | 92-е
| AV Исключить кеш и код | 38s | 104 с | 29 с | - | - | - | - | -
| Av Исключить только кеш | 43 с | - | 31 с | - | - | - | - | -
| Av полный | 48s | 122с | 32с | 100-е | 274s | 236с | - | -

Каждый раз, когда AV был включен, он достигал вершины диаграммы ЦП в течение yarn install или xcopy (на моем домашнем ПК 30% общего количества ЦП было занято максимумом, но на моем рабочем ПК он заполняет одно ядро ​​для xcopy и все мои стержни для пряжи)
xcopy медленнее на моем рабочем ПК, чем yarn, я подозреваю, потому что он не копирует файлы параллельно, в то время как yarn делает (это не имеет значения для операций, связанных с вводом-выводом, но AV делает его операцией, привязанной к процессору, а xcopy не записывается в бороться столько глупостей 😄)

В заключении

• yarn быстрее, чем npm и даже может быть быстрее, чем xcopy когда AV делает копию файла, связанную с ЦП
• Windows на хорошем SSD на самом деле не медленнее, чем MacBook Pro 2015 (у которого уже есть хороший SSD), даже если сравнивать сложно, так как устанавливаются не совсем одинаковые пакеты, и не все сценарии после установки делают одно и то же
• Некоторые изменения могут быть внесены в пряжу, чтобы обойти это (символические файлы?), Но по существу копирование большого количества небольших файлов происходит медленно.
• В Windows AV может сделать его медленнее , мой добавляет 30% при включении как в исходной, так и в целевой папках 😞
• Корпоративные AV могут быть намного

Добавление npm, папок кэша пряжи и node.exe в список исключений защитника было бы достаточно, конечно, все это не может быть в индексированных папках. Теперь добавление пряжи / погон занимает 7 секунд.

Всем спасибо, значительная оптимизация для Windows произошла в 0.24 https://github.com/yarnpkg/yarn/pull/3234#issuecomment -297552326

@vbfox Не могли бы вы добавить номера версий для npm и yarn в свой тест?

это еще говно для MacOSX

Я все еще испытываю сумасшедшее время установки. yarn add кажется, устанавливает и связывает все (все элементы в package.json , ~ 30k зависимостей) все время.

Версии 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?

   • Если решение касалось настройки Защитника Windows, есть ли полное описание того, что где-то делать?

2. Действительно ли моя проблема связана с этой веткой, или мне следует создать новую?

Спасибо, что подняли новую проблему, я отвечу там

Прошёл почти час, и я жду, пока эта команда завершит процесс. Я следил за пунктами выше, упомянутыми @Altiano, но ничего не работает

у нас есть альтернатива этому? например, могу ли я использовать npm i -g . будет ли он действовать таким же образом, или мне придется внести некоторые изменения, потому что этот код использует пряжу workspace

Итак, наконец, после двух-трех часов борьбы, мне пришлось использовать npm i -g . вместо yarn global add file:. . npm работал как шарм