Yarn: Necesita una gran optimización para Windows

+1

¡Hola @OshotOkill! Gracias por probar Yarn. ¿Está utilizando Cygwin o WSL ("Bash en Ubuntu en Windows")? Se sabe que ambos tienen un rendimiento de E / S de disco bastante malo.

Además, React Native tiene una gran cantidad de archivos, por lo que copiarlos en node_modules es bastante lento, y la E / S de disco para muchos archivos pequeños en Windows es generalmente más lenta que Mac OS (que a su vez es más lenta que Linux ext4). Tenemos la tarea de experimentar con enlaces duros (# 499) que deberían mejorar el rendimiento en este escenario.

Sin caché y mismo entorno de red

La principal mejora con Yarn es cuando tiene un caché caliente (es decir, después de haber instalado un paquete al menos una vez), pero con React Native, la gran cantidad de archivos también será una causa de la lentitud.

@ Daniel15 No, no estoy usando Cygwin / MinGW / MSYS2 o WSL (este último falla debido a un error complicado).

De acuerdo con su descripción, puedo asumir que el problema es causado por el sistema de archivos (NTFS), ¿verdad? Incluso si existe una caché caliente, el proceso de copia aún se ejecuta mucho más lento que MacOS.

Espero que los equipos de desarrollo puedan encontrar una solución lo antes posible. Gracias.

Estoy viendo lo mismo.

Instalar, borrar node_modules, instalar

MacBookPro tarda 17 segundos, mi máquina Windows tarda 122 segundos.

Alguien señaló que esto podría estar relacionado con el software antivirus que escanea los módulos node_modules y el caché de hilo global de forma continua. ¿Puedes intentar deshabilitarlo para esas carpetas?

@cpojer Supongo que tienen razón. No tengo ningún software antivirus en mi máquina, excepto el Windows Defender preinstalado, por lo que prohibí el escaneo de la carpeta de caché global y la carpeta de mi proyecto e hice algunas pruebas:

Predeterminado: 128.08s

Sin escaneo de la carpeta de caché: 104.43s

Sin escaneo de la carpeta del proyecto: 78.28 s

Sin escaneo de la carpeta de caché y la carpeta del proyecto: 53.48 s

Aunque es más lento que Mac durante 10+ s, tiene un impulso significativo.

Esto debería ser informado de los documentos oficiales, creo.

Alguien señaló que esto podría estar relacionado con el software antivirus que escanea los módulos node_modules y el caché de hilo global de forma continua.

¡Buena atrapada! Me olvidé por completo de esto porque ya tengo c:\src lista blanca en mis computadoras.

@OshotOkill : ¿Le gustaría enviar una solicitud de extracción agregando una nota sobre las aplicaciones antivirus en el sitio web, en las instrucciones de instalación de Windows? Aquí está el archivo que necesitaría editar: https://github.com/yarnpkg/website/blob/master/en/docs/_installations/windows.md (puede editarlo directamente en Github). Sería apreciado 😄

No fui tan meticuloso como @OshotOkill , pero agregué excepciones para mi fuente y la carpeta de instalación de mi nodo, y luego eximí específicamente los binarios de yarn, npm y nodos y ahora mi tiempo de instalación nuevo en Windows se ha reducido a 50 segundos desde 122 segundos .

@ Daniel15 PR está listo. Disculpe mi pobre inglés.

PR se ha fusionado. Cierra este problema.

Esto sigue siendo dolorosamente lento en Windows, incluso desactivando el antivirus y el defensor de Windows. No creo que sea solo un problema de entorno (como esta solución antivirus), pero parece que yarn intenta copiar todos los archivos, 1 por 1, incluso si instala alguna dependencia no relacionada.

¿Por qué no simplemente eliminar / copiar los archivos que necesitan cambiar? Si tenía webpack instalado y no se modificó cuando instalé rimraf , no debería tener que ser copiado nuevamente desde el caché a la carpeta local node_modules.

También he creado un artículo de StackOverflow sobre esto: http://stackoverflow.com/questions/40566222/yarn-5x-slower-on-windows

Por cierto, en mis pruebas de rendimiento de Ubuntu (de arranque dual), estaba usando la misma unidad NTFS en la que normalmente se ejecuta Windows; y todavía es rápido allí.

Agregar node.exe a las exclusiones de Windows Defender me dio un gran aumento de rendimiento http://126kr.com/article/1884rsed7l

¡Definitivamente probaré esto!

Pareció mejorar un poco la velocidad 212 -> 170 segundos
Entonces parece ayudar, pero aún podría mejorarse, porque sigue siendo más de 3 veces más lento que en Linux

Otro problema que he notado: el servicio de indexación en Windows intenta indexar todos los archivos en node_modules.
Realmente no lo necesito en absoluto, así que lo desactivé http://www.softwareok.com/?seite=faq-Windows-10&faq=53 y obtuve otro aumento de rendimiento.

Mis ventanas no están configuradas para indexar la ruta en cuestión, por lo que aún no resuelve el problema.

Entonces, para resumir, hay 4 formas de mejorar el rendimiento:

• Carpeta de proyecto de lista blanca de AV
• Mientras que el directorio de caché de Yarn ((% LocalAppData% Yarn)) de AV
• Agregar node.exe a las exclusiones de Windows Defender
• Deshabilitar el servicio de indexación en Windows en la carpeta node_modules

@Altiano sí, pero aún no es suficiente para obtener un rendimiento ni siquiera cerca de Mac / Linux

Parece un poco incompleto que tendría que deshabilitar AV o la indexación en directorios para hacer hilo tan rápido o más rápido que npm. Después de todo, no tiene que hacer esto para npm. Decidí darle una oportunidad a Yarn porque decía que era rápido y las instalaciones fuera de línea hicieron que la codificación sin conexión de red fuera algo plausible. ¿No hay forma de optimizar el enlace?

De acuerdo con algunos problemas que se relacionan aquí y los comentarios anteriores, me gustaría reabrir este problema para reunir algunas otras soluciones.

Personalmente, sugiero enumerar las configuraciones de hardware de su máquina de prueba y cargar algunas fotos relacionadas. Podría haber muchos otros elementos irrelevantes que marcan una gran diferencia entre las plataformas en lugar de Yarn en sí, es decir, el rendimiento de referencia del SSD en una MacBook suele ser mucho mejor que en una máquina con Windows.

@OshotOkill, como dije antes, obtuve un rendimiento 3.5 veces más lento en Windows que en Linux con índices y Windows Defender deshabilitados para los directorios relevantes, en la misma PC normal en la misma unidad _ntfs_. Que incluso en NTFS sea mucho más rápido en Linux dice mucho, creo.

Vayamos a la razón de esto.
¿Podría ser NTFS funcionando más lento en una gran cantidad de archivos que se mueven durante la instalación?

¿Alguien puede compartir una forma de reproducir esto en una sola máquina?
Por ejemplo, un package.json en particular instalado en una computadora portátil con Windows tarda X segundos pero ejecutarse en VirtualBox Ubuntu X-20% segundos.

@amcsi @bestander Como suele ser el caso, EXT4 / XFS son más rápidos al copiar grandes cantidades de archivos pequeños. Sin embargo, NTFS no es mucho más lento. Acabo de limpiar el caché y lo probé nuevamente usando la última versión de Yarn and Node (0.19.1 y 7.5.0):

El resultado es muy parecido al de una MacBook al instalar react-native . Todo lo que hice fue incluir en la lista blanca las carpetas relacionadas y el proceso Node.exe.

Yo mismo estaba teniendo este problema hasta que incluí en la lista blanca los procesos node.exe y yarn.exe en Windows Defender, junto con el directorio de mi proyecto. No he desactivado la indexación de búsqueda en absoluto, ni he incluido en la lista blanca el directorio de caché de Yarn. Los tiempos de instalación pasaron de más de 190 segundos en un proyecto de tamaño mediano a aproximadamente 25 segundos en un caché limpio. Mi máquina Ubuntu es un poco más rápida que eso, pero solo de 5 a 10 segundos.

Configuración de hardware:
SSD de 512 GB
12 GB de RAM
CPU AMD FX-8350 de 8 núcleos a 4.01 GHz
Windows 10 de 64 bits, compilación 14986.

Acabo de hacer algunas pruebas rápidas en mi propio sistema. Tengo Linux Mint y Windows 10 con arranque dual desde el mismo SSD. Limpié mi caché de hilo, eliminé node_modules y ejecuté yarn en este proyecto vue .

Linux Mint: _12.22s_

Windows 10 (sin lista blanca): _64.32s_

Windows 10 (con lista blanca): _42.58s_

Estas fueron las exclusiones de Windows Defender que tenía activas:

Si bien la lista blanca parecía tener un efecto significativo, aún no se acercaba a igualar la velocidad en Linux.

EDITAR: Para @bestander , aquí están mis datos normalizados:

| OS | Cálculo | Datos normalizados |
| --- | --- | --- |
| Linux Mint | 12,22 / 12,22 | 1 |
| Windows 10 | 64,32 / 12,22 | 5,2635 |
| Windows 10 (con lista blanca) | 42,58 / 12,22 | 3,4845 |

@keawade Tenía 26.48s para instalar tu proyecto desde un caché limpio y 13.58s para instalarlo con el caché.

Solo escupiendo aquí, estoy usando Yarn.cmd del instalador de MSI y parece que estás usando Yarn instalado desde NPM. Me pregunto si tal vez haya una discrepancia entre ellos.

@nozzlegear Si bien eso podría ser posible, creo que es menos probable que debido a las diferentes conexiones a Internet.

Necesitamos eliminar la red de esto.
Actualmente puedo probar este repositorio en una última versión de Windows 10 con la función "Linux en Windows" habilitada.
Tanto a través de CMD como de Bash con cachés principales, la instalación tarda entre 27 y 29 segundos en un procesador i7 de 2 núcleos.

@keawade , ¿puedes ejecutar la misma prueba con node_modules eliminado pero con cachés en su lugar?

No puedo instalar un segundo sistema operativo en el dispositivo que tengo todavía.
¿Alguien puede comprobar si ejecutar Windows y Linux en una caja virtual da resultados diferentes?

Construí el maestro actual con marcas de tiempo https://github.com/yarnpkg/yarn/releases/download/v0.21.0-pre/yarn-0.21.0-0.js

¿Puedes usarlo para instalar con la bandera --verbose ?

P.ej

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

Debe dar marcas de tiempo a todas las operaciones de FS

Datos sin limpiar cachés

_Nota: Estos datos se registran en un sistema de arranque dual. Todo el hardware es idéntico para estas pruebas.

| OS | Tiempo medio | Normalizado |
| ----------------------------- | ---------- | -------- ---- |
| Linux Mint | 5.598s | 1,00000 |
| Windows 10 (con lista blanca) | 12.119s | 2,16488 |
| Windows 10 (sin lista blanca) | 31.578s | 5,64094 |

_Avg Time es el promedio de un conjunto de 10 pruebas_

Datos sin procesar de Linux Mint

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

Datos sin procesar de Windows 10

Con listado blanco

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

Sin lista blanca

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

Metodología

Usé este script de PowerShell para generar todos los datos que se muestran aquí. El script clona este repositorio y ejecuta 10 iteraciones del comando yarn , eliminando node_modules después de cada iteración.

@bestander , he actualizado la publicación anterior con los datos de Windows.

Genial, gracias por más datos.
¿Puedes probar la versión --verbose con yarn.js con marcas de tiempo para ambos sistemas operativos?
Nos daría una buena idea de dónde se pasa el tiempo.

¡Vaya, eso es mucho registro! ¿Quiere 10 ejecuciones para cada combinación de OS / lista blanca o es suficiente una para cada combinación?

@bestander ¡ Aquí tienes! Uno de cada uno.

Nota al margen: resulta que si intentas cargar ~ 30 MB de texto sin formato en una sola colección esencial, obtienes un error nginx 405. 😆

~ Linux Mint ~
~ Windows 10 con exclusiones y con limpio ~
~ Windows 10 con exclusiones y sin _clean_ ~
~ Windows 10 con limpio y sin _exclusiones_ ~
~ Windows 10 sin _exclusiones_ y _sin_ limpiar ~

VerboseLogs.tar.gz

EDITAR: Eliminando gists y cargando los archivos comprimidos.

Resulta que si intenta cargar ~ 30 MB de texto sin formato en una sola colección de gist, obtiene un error nginx 405. 😆

Puede comprimir los archivos (bzip2 o 7-Zip) y adjuntarlos aquí ... El texto sin formato se comprime muy bien :)

@ Daniel15 Buen punto, aquí están los archivos comprimidos: VerboseLogs.tar.gz

1 carrera estaría bien :)

Comparé LinuxMint.txt vs Windows10NoClean.txt

Linux:

• La fase de vinculación comienza en 1,156 segundos.
• todas las carpetas dentro de node_modules creadas en 1.968
• último archivo copiado a los 3.873 segundos
• las construcciones se realizan en otros 3 segundos

Ventanas

• la fase de vinculación comienza en 2.779 segundos
• todas las carpetas dentro de node_modules creadas en 4.83
• último archivo copiado en 32.853
• las construcciones se realizan en otros 3 segundos

Obviamente, el registro detallado afecta el tiempo de ejecución en Windows (12 -> 35 segundos) pero no en Linux (los mismos 6 segundos).

De los puntos de referencia que encontré en Internet, Linux EXT3 FS generalmente supera a NTFS cuando se copian muchos archivos.
Me pregunto si este es el límite que tenemos que afrontar.

@keawade , ¿las velocidades son diferentes cuando se usa npm @ 3 en Windows y Linux?

Algunas ideas:

• Windows puede ser malo en la copia simultánea, copiamos archivos en 4 subprocesos. ¿Quizás hacerlo de un solo hilo?
• Tal vez use el contenedor robocopy en Windows https://github.com/mikeobrien/node-robocopy
• usamos readstream.pipe.writestream para copiar archivos, tal vez sea ineficiente en Windows

Si está ansioso por experimentar, reemplace 4 con 1 en https://github.com/yarnpkg/yarn/blob/master/src/util/fs.js#L322 y vea si la copia de un solo hilo se vuelve más rápida en Windows

Pruebas de hilo

Por solicitud de bifurqué yarnpkg/yarn y modifiqué la línea 322 de src/util/fs.js , reemplazando 4 con 1 . Luego usé yarn run build para construir el proyecto y ejecuté 10 pruebas con esa compilación usando el yarn.cmd que fue compilado por la compilación. Estos son los resultados.

| | Tiempo medio | Normalizado |
| ---------------------------- | ---------- | --------- --- |
| Windows 10 (con lista blanca) | 12.119s | 1,00000 |
| Hilo de copia única | 16,927s | 1,39673 |
| Hilo de copia única + Limpiar | 42.268s | 3.48775 |

_Avg Time es el promedio de un conjunto de 10 pruebas_

Parece que usar un solo hilo para copiar los archivos da como resultado tiempos de instalación ligeramente más lentos.

Datos brutos

Windows 10 (con lista blanca)

Estos datos son de una prueba anterior

Hilo de copia única

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

Hilo de copia única + Limpiar

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

Gracias, @keawade.
¿Puede verificar mi suposición de que NTFS podría ser más lento para copiar una gran cantidad de archivos que Linux FS?

Mida la copia a través de los módulos node_modules completamente instalados en el terminal a otra ubicación tanto en Linux Mint como en Windows 10, por favor.

También es necesario probar la copia usando robocopy con la opción /mt (copias multiproceso)

También me gustaría informar de un error posiblemente informado, en el que cada yarn add o yarn remove tarda entre 30 y 40 minutos. Aparentemente copia TODAS las dependencias nuevamente, y como estoy en Windows, esto lleva mucho tiempo. Ver problema vinculado:

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

@kumarharsh # 2458 Me tomó 28

También debo mencionar que no olvides incluir también en la lista blanca las carpetas del proyecto, no solo el caché.

Copiar pruebas

Usé este script para ejecutar 10 iteraciones de copias tanto en Linux Mint como en Windows 10. Copié este repositorio después de ejecutar yarn en el directorio. Estos son mis resultados.

| OS | Tiempo medio | Normalizado |
| ------------ | ------------ | ------------ |
| Linux Mint | 1527.4620 | 1,00000 |
| Windows 10 | 53676.3155 | 35,14085 |

Esa diferencia horaria es una locura. Estas copias se realizaron copiando archivos de una ubicación a otra en _el mismo SSD_.

Datos brutos

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

No tengo tiempo en este momento para probar robocopy pero puedo obtener esos datos esta noche después del trabajo.

Prueba de robocopia

Usé este script para ejecutar 10 iteraciones de copias tanto en Linux Mint como en Windows 10. Copié este repositorio después de ejecutar yarn en el directorio. Estos son mis resultados.

| OS | Tiempo medio | Normalizado |
| ----------------------- | ------------ | ------------ |
| Linux Mint | 1527.4620 | 1,00000 |
| Windows 10 | 53676.3155 | 35,14085 |
| Windows 10 (Robocopy) | 58089.7457 | 38.03024 |

Robocopy funcionó un poco peor que una copia normal.

Datos brutos

Los valores de Linux Mint y Windows 10 son de las pruebas anteriores

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

@keawade , ¿puede verificar que la indexación de archivos y Defender no interfieran con la copia?
Afaik puede involucrarse incluso para un comando cp.

Compruebe qué está activo en el Administrador de tareas cuando se realiza la copia.
Y tal vez simplemente apague esos servicios para una prueba

Pruebas de indexación y defensa

Realicé pruebas en las siguientes condiciones:

• Con Windows Defender deshabilitado
• Con el servicio de indexación de Windows deshabilitado
• Con _ambos_ deshabilitados Windows Defender y el servicio de indexación de Windows
• Con _ambos_ Windows Defender deshabilitado y el servicio de indexación de Windows _y_ limpiando la caché de Yarn

Para deshabilitar Windows Defender, desactivé Real-time protection en el panel de configuración de Windows Defender .

Para deshabilitar la indexación de Windows, detuve el servicio de búsqueda de Windows en el panel de control de Servicios .

_Nota: cuando se habilitó Windows Defender, no se enumeraron exclusiones_

Usé este script para ejecutar 10 iteraciones de copias tanto en Linux Mint como en Windows 10. Copié este repositorio después de ejecutar yarn en el directorio. Estos son mis resultados.

Resumen

Parece que aunque la indexación de Windows (servicio de búsqueda) tiene un impacto en las operaciones de copia y Yarn, el mayor impacto proviene de Windows Defender.

Proceso de copiar

| OS | Tiempo medio | Normalizado |
| -------------------------------------------- | ---- -------- | ------------ |
| Linux Mint | 1527.4620 | 1,00000 |
| Windows 10 (sin defensor) | 7301.4307 | 4,78011 |
| Windows 10 (sin indexación) | 10307.0794 | 6,74787 |
| Windows 10 (sin defensor, sin indexación) | 7044.1393 | 4.61166 |
| Windows 10 Robo (sin defensor, sin indexación) | 10094.8358 | 6.60889 |

Indexación La desactivación total de la indexación y el antivirus proporciona un gran impulso al rendimiento al copiar archivos.

Hilo

Dado que los resultados anteriores fueron tan pronunciados, pensé que probablemente también podríamos usar datos sobre el rendimiento de Yarn en estas condiciones.

Usé este script para ejecutar 10 iteraciones de yarn tanto en Linux Mint como en Windows 10. Cloné este repositorio y ejecuté yarn en el directorio.

| OS | Tiempo medio | Normalizado |
| --------------------------------------------- | --- ------- | ------------ |
| Linux Mint | 5.5980 | 1,00000 |
| Windows 10 (sin defensor) | 16,5450 | 2,95552 |
| Windows 10 (sin indexación) | 38,5170 | 6,88049 |
| Windows 10 (sin defensor, sin indexación) | 16,8490 | 3,00982 |
| Windows 10 Clean (sin defensor, sin indexación) | 30,7730 | 5,49714 |

Datos brutos

Los valores de Linux Mint son de las pruebas anteriores .

Elemento de copia de Windows 10

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

Robocopy de Windows 10

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

Hilado de Windows 10

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

Limpieza de hilo de Windows 10

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

Indexación de hilos de Windows 10 deshabilitada

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

Indexación de copia de Windows 10 deshabilitada

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

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

Copia de Windows 10 Windows Defender deshabilitado

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

Esa es una investigación sólida, @keawade , gracias por compartir todos los datos.
Los datos sugieren que el rendimiento del sistema de archivos sin procesar es el cuello de botella para las instalaciones de hilos en Windows.
No estoy seguro de si Yarn puede hacer algo aquí a menos que haya algún comando de copia inteligente que solucione la limitación

@keawade gracias por tomarse tanto @bestander podría ser que desdemamá npm no enfrenta estos mismos problemas al copiar (escaneo perpetuo), ¿tal vez el hilo no está firmado? Podría ser que Windows Defender no confíe en hilo al mismo nivel que npm. Solo un pensamiento...

@kumarharsh , entonces tendremos que medir la diferencia entre npm e hilo.
Tal vez npm esté copiando menos archivos (la elevación de Yarn no está optimizada para el árbol de módulos de nodo más pequeño).
Y sería genial si pudiéramos incluir automáticamente el hilo en la lista blanca a través del instalador.

tal vez el hilo no está firmado? Podría ser que Windows Defender no confíe en hilo al mismo nivel que npm.

No creo que los scripts se puedan firmar (con la excepción de los scripts de PowerShell que admiten firmas Authenticode), por lo que no creo que Yarn y npm difieran en ese sentido. El instalador de Yarn está firmado por Authenticode como el de npm.

Y sería genial si pudiéramos incluir automáticamente el hilo en la lista blanca a través del instalador.

Siento que tocar automáticamente una lista blanca de escaneo de virus daría como resultado que los escáneres de virus marquen el instalador como malware. Parece una cosa arriesgada. Sin embargo, quizás podríamos incluir automáticamente el directorio en la lista negra en el indexador de búsqueda.

@keawade He probado robocopy con las opciones /E /MT (copias multiproceso).

| Método de copia | Tiempo medio |
| ---------------------- | ---------- |
| Copiar artículo -Recurse | 20219 |
| Robocopy /E | 26652 |
| Robocopy /E /MT | 9043 |

Datos brutos (windows 10)

Copiar artículo -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]

No creo que los scripts se puedan firmar (con la excepción de los scripts de PowerShell que admiten firmas Authenticode), por lo que no creo que Yarn y npm difieran en ese sentido. El instalador de Yarn está firmado por Authenticode como el de npm.

Suena razonable.
¿Podemos comprobar esto?
Si ejecuta npm install aparecen Indexer y Defender en el Administrador de tareas?

Pruebas de indexación y defensor de NPM

Registré el tiempo que tardó en ejecutar npm install en este repositorio en el mismo conjunto de condiciones que las pruebas de indexación y defensa para los métodos de copia de Yarn y Windows.

| OS | Tiempo medio | Normalizado |
| --------------------------------------------- | --- ------- | ------------ |
| Linux Mint (hilo) | 5.5980 | 1,00000 |
| Linux Mint (NPM) | 28,9793 | 5.17672 |
| Windows 10 (sin defensor) | 42,6296 | 7,61514 |
| Windows 10 (sin indexación) | 53,8791 | 9,62470 |
| Windows 10 (sin defensor, sin indexación) | 37,9727 | 6,78326 |
| Windows 10 (sin alteraciones) | 58.5047 | 10,45100 |

Resumen

Parece que NPM también se ve afectado por Windows Defender.

Datos brutos

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 con Windows Defender deshabilitado

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

NPM con la indexación de Windows deshabilitada

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

NPM con Windows Defender y la indexación de Windows deshabilitada

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

Supongo que tendremos que solucionar la limitación de que Windows sea más lento en la E / S de disco reduciendo el número de operaciones de E / S en general y educando a la gente sobre Indexación y Defender.
Reemplazar copy con robocopy también parece una buena idea.

reducir el número de operaciones IO en general

Esta es una buena idea en general y ayudará a realizar en todas partes. También podría ser bastante beneficioso para las personas que crean en servidores con discos duros lentos.

Esperamos que un PR para reemplazar la tubería de flujos fs con una copia automática en Windows aquí .

- actualización
Sin embargo, esto podría no ser óptimo porque copyBulk tiene una lógica adicional como exclusiones que podrían no traducirse en un solo comando robocopy.

¿Alguien sabe por qué me pasa esto (siempre)?

Para ampliar la publicación:
En mi máquina con Windows, cada yarn add o yarn rm vuelve a copiar todos los módulos de nodo en mi proyecto, lo que hace que cada cambio en package.json tarde un tiempo insoportablemente largo en completarse. Esa barra de progreso para dependencias de 160k viene todo el tiempo y se arrastra como una tortuga varada en un campo petrolífero. ¡Observe los tiempos en la operación yarn rm paper que hice antes de los yarn add - 1000 segundos!

Y cancelar una de esas operaciones add/rm no es posible, ya que estropea la carpeta node_modules y cualquier yarn install / npm install posterior no instalará todas las dependencias, lo que en última instancia significa que termino haciendo un rm -r node_modules/ y comenzando de nuevo. Esta única razón es lo suficientemente dolorosa como para evitar que use la instalación de hilo.

Creo que tienes node_modules mal montados, este error se solucionará en # 2676

Con la introducción de @bestander de hardlinking en # 2620 (que funciona bien en Windows 7 sin privilegios de administrador), mis tiempos de instalación generales y el tamaño de node_modules/ disminuyeron.

Sin intransigencias:

Done in 167.76s.

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

du -sh node_modules/
216M    node_modules/

Con hardlinking:

Done in 58.07s.

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

du -sh node_modules/
189M    node_modules/

Espere 0.21.1, tendrá la solución de @kittens para izar.
Debería ser aún más rápido

El miércoles 15 de febrero de 2017 a las 20:04, Hutson Betts [email protected] escribió:

Con @bestander https://github.com/bestander la introducción de
vínculo duro en # 2620 https://github.com/yarnpkg/yarn/pull/2620 (que
funciona bien en Windows 7 sin privilegios de administrador), mi
tiempos de instalación, y node_modules / size, eliminados.

Sin intransigencias:

Hecho en 167,76 s.

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

du -sh node_modules /
216M módulos_nodo /

Con hardlinking:

Hecho en 58.07s.

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

du -sh node_modules /
189M módulos_nodo /

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/yarnpkg/yarn/issues/990#issuecomment-280122923 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/ACBdWAEghXfPo4bX9mN0hV8l8YaH2rmlks5rc1pigaJpZM4KVwpA
.

Estoy en Win7 / w Yarn v0.21.3

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

Tuve que esperar esta cantidad de tiempo para agregar cualquier paquete nuevo con yarn add ...
Defensor fuera
Indexación deshabilitada

Tenga algún otro AV en ejecución, así que solo siga estos pasos como lo mencionó @Altiano

Carpeta de proyecto de lista blanca de AV
Mientras que el directorio de caché de Yarn ((% LocalAppData% Yarn)) de AV

Se actualizará en este

@kuncevic , ¿cuál sería un tiempo de instalación limpio para el proyecto?
¿Cuál es el tamaño de la carpeta node_modules en los archivos?
¿Cómo se compara con la instalación de npm?

@bestander, este es el mismo problema conmigo. Cualquier yarn add o yarn remove toma el mismo tiempo, aproximadamente, incluso después de las correcciones de elevación de @kittens .

Cada vez que esto sucede:

1. Primero, el Fetching packages ejecuta (tarda unos 30 segundos):
   
2. Luego, la vinculación de dependencias se detiene durante aproximadamente 1 o 2 minutos.
   
3. Luego, continúa con el siguiente paso e instala (?) 63k archivos nuevamente.
   

Como dije, esto sucede cada vez que ejecuto yarn add o yarn remove . No importa si la dependencia que estoy instalando depende de cualquier otra dependencia. Un simple npm install para instalar una nueva dependencia o actualizar una existente toma una fracción de este tiempo. Las cosas mejoraron en 2x con las correcciones de izado de @kittens , pero aún así el tiempo necesario es demasiado.

@bestander si desea un caso reproducible, clone este repositorio: https://github.com/kumarharsh/yarn-bug , y ejecute yarn install , y luego yarn add react-helmet .

Yarn conserva el determinismo cada vez que ejecuta add / remove, por lo que debe verificar si alguna dependencia se subió a la raíz de node_modules cuando las dependencias cambian.
Es por eso que se ejecuta en fase de vinculación completa.

Obteniendo dependencias: descarga, no puedes optimizarlo.
Primera fase de vinculación (1561 operaciones): crea todas las carpetas para todas las dependencias.
Segunda fase de vinculación (operaciones de 63K): copia los archivos de la caché a node_modues.

Yarn optimiza las operaciones de copia de archivos comprobando si los archivos son iguales antes de realizar la copia.
Es posible que queramos perfilar mejor esta área y ver si podemos reducir el número de E / S innecesarias.
¿Quizás en Windows copiar sería más rápido que verificar?

¿Qué pasa con npm, qué tan rápido se instala de forma limpia?

Una instalación limpia para npm ( npm install ) requiere 552301.1944ms .
La instalación de una dependencia adicional ( npm install weird ) requiere 57023.7593ms . (La mayor parte de este tiempo se pierde en paperjs tratando de instalar canvas como depósito, pero este tiempo sería común para npm e yarn)

Una instalación limpia para hilo ( yarn install ) requiere 612698.4915ms .
La instalación de una dependencia adicional ( yarn add weird ) requiere 495633.0307ms .

npm version 3.10.9
yarn version 0.21.3

@bestander @kumarharsh Yarn no optimiza las operaciones de copia de archivos en Windows debido a un error libuv / nodejs (Ver # 2958 para una posible solución en el código de hilo) que no está presente en el nodo 7.1+ para que pueda obtener su segundo comando ( yarn add ) para ser mucho más rápido con solo actualizar node.

Usar la operación de copia de archivos de Windows es un poco más rápido que usar la API de nodo para copiar archivos también (Ver # 2960 para un PR potencial) y optimizaría yarn install un poco, pero no sé si se igualaría con npm (no probó)

Recién actualizado a 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.

Sin embargo, al hacer yarn add rimraf lo hice en 20.52s. pero ¿por qué yarn install después de eliminar node_modules tardando tanto?

PD

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 Es bueno ver que el nodo de actualización funciona por yarn add :)

Con respecto a los node_modules vacíos, una buena cosa es medir cuánto se debe al hilo y cuánto se debe al sistema de archivos, disco duro y antivirus.
Lo que hice para probar eso fue copiar el node_module completo (generado por hilo, no npm) de material2 en algún lugar de la caché de hilo:

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

Y luego, para cada prueba, limpié node_modules y ejecuté yarn install , npm install o un xcopy de la carpeta creada anteriormente:

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

Y tomó el total de segundos.

Resultados

Aquí están los resultados en 3 PC

• 🏠 PC doméstica: Samsung 950 Pro NVMe, ESET Nod32
• 🏢 PC de trabajo: Samsung 850 EVO SATA, TrendMicro OfficeScan que no puedo desactivar
• 🍎 MacBook pro: versión 2015, en macos, sin antivirus

|| yarn 🏠 | npm 🏠 | xcopy 🏠 | yarn 🏢 | npm 🏢 | xcopy 🏢 | yarn 🍎 | npm 🍎
| - | - | - | - | - | - | - | - | -
| AV discapacitado | 34 s | 90s | 23s | - | - | - | 32s | 92
| AV Excluir caché y código | 38s | 104s | 29s | - | - | - | - | -
| Av Excluir solo caché | 43 s | - | 31 s | - | - | - | - | -
| Av completo | 48s | 122s | 32s | 100s | 274s | 236s | - | -

Cada vez que se habilitó AV, encabezó la tabla de CPU durante yarn install o xcopy (En mi PC de casa, el 30% del total de la CPU se tomó al máximo, pero en mi PC de trabajo llenó un núcleo para xcopy y todos mis núcleos de hilo)
xcopy es más lento en mi PC de trabajo que yarn, sospecho que porque no copia archivos en paralelo mientras que yarn lo hace (eso no debería importar para las operaciones vinculadas de IO, pero AV lo está convirtiendo en una operación vinculada a la CPU y xcopy no se escribió en luchar contra tanta estupidez 😄)

En conclusión

• yarn es más rápido que npm e incluso puede ser más rápido que xcopy cuando el AV hace que la copia de archivos esté vinculada a la CPU
• Windows en un buen SSD no es realmente más lento que un MacBook Pro 2015 (que ya tiene un buen SSD) incluso si es difícil de comparar, ya que no se instalan exactamente los mismos paquetes y no todos los scripts posteriores a la instalación hacen lo mismo
• Se podrían hacer algunos cambios en el hilo para eludir eso (¿archivos de enlace simbólico?), Pero esencialmente manejar muchos archivos pequeños es lento
• En Windows AV puede hacerlo más lento , el mío agrega un 30% cuando está habilitado en las carpetas de origen y destino 😞
• Los AV corporativos pueden ser una magnitud más lentos que los AV domésticos y matar el rendimiento lo suficiente como para que cualquier operación de copia sea dolorosa (cuando hace que la operación vinculada naturalmente a la IO esté vinculada a la CPU)

Agregar npm, carpetas de caché de hilo y node.exe a la lista de exclusión del defensor sería suficiente, por supuesto, todo esto no puede estar en carpetas indexadas. Ahora la adición de hilo / rm tarda 7 segundos

Gracias a todos, una optimización significativa para Windows aterrizó en 0.24 https://github.com/yarnpkg/yarn/pull/3234#issuecomment -297552326

@vbfox ¿Puede agregar números de versión para npm y yarn en su punto de referencia?

esto sigue siendo una mierda para MacOSX

Todavía estoy experimentando algunos tiempos de instalación locos. yarn add parece instalar y vincular todo (todos los elementos en package.json , ~ 30k dependencias) todo el tiempo.

Versiones de Linux:

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

Versiones de 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

Tengo dos (y media) preguntas:

1. ¿Cuál es la solución aceptada al problema en este hilo? ¿Era # 3234 o estaba modificando Windows Defender?

   • Si la solución fue modificar Windows Defender, ¿hay una descripción completa de qué hacer en alguna parte?

2. ¿Mi problema está realmente relacionado con este hilo o debería crear uno nuevo?

Gracias por plantear un nuevo problema, responderé allí.

Ha pasado casi una hora y estoy esperando que este comando termine el proceso. He seguido los puntos anteriores mencionados por @Altiano pero nada funciona

¿Tenemos alguna alternativa para esto? como ¿puedo usar npm i -g . actuará de la misma manera o tendré que hacer algunos cambios porque este código usa hilo workspace

Entonces, finalmente, después de luchar durante 2-3 horas, tuve que usar npm i -g . lugar de yarn global add file:. . npm funcionó como un encanto