Yarn: Precisa de uma grande otimização para o Windows

+1

Olá @OshotOkill! Obrigado por experimentar o Yarn. Você está usando Cygwin ou WSL ("Bash no Ubuntu no Windows")? Ambos são conhecidos por terem um desempenho de IO de disco muito ruim.

Além disso, React Native tem um grande número de arquivos, portanto, copiá-los para node_modules é muito lento, e IO de disco para muitos arquivos pequenos no Windows é geralmente mais lento do que o Mac OS (que por si só é mais lento que o Linux ext4). Temos a tarefa de experimentar hardlinks (# 499), o que deve melhorar o desempenho neste cenário.

Sem cache e mesmo ambiente de rede

A principal melhoria com o Yarn é quando você tem um cache aquecido (ou seja, depois de instalar um pacote pelo menos uma vez), mas com o React Native, o grande número de arquivos também será a causa de parte da lentidão.

@ Daniel15 Não, não estou usando Cygwin / MinGW / MSYS2 ou WSL (o último falha devido a um bug complicado).

De acordo com sua descrição, posso assumir que o problema é causado pelo sistema de arquivos (NTFS), certo? Mesmo que exista um cache aquecido, o processo de cópia ainda será executado muito mais lentamente do que o MacOS.

Espero que as equipes de desenvolvimento possam encontrar uma solução o mais rápido possível. Obrigado.

Estou vendo o mesmo.

Instale, limpe node_modules, instale

MacBookPro leva 17 segundos, minha máquina Windows leva 122 segundos.

Alguém apontou que isso pode estar relacionado à varredura de node_modules do software antivírus e ao cache global de fios continuamente. Você pode tentar desativá-lo para essas pastas?

@cpojer Acho que eles estão certos. Não tenho nenhum software antivírus na minha máquina, exceto o Windows Defender pré-instalado, então bani a verificação da pasta de cache global e da pasta do meu projeto e fiz alguns testes:

Padrão: 128.08s

Sem verificação da pasta de cache: 104,43s

Sem digitalização da pasta do projeto: 78,28s

Sem varredura de pasta de cache e pasta de projeto: 53,48s

Embora seja mais lento do que o Mac para 10 + s, tem um impulso significativo.

Isso deve ser informado a partir dos documentos oficiais, eu acho.

Alguém apontou que isso pode estar relacionado à varredura de node_modules do software antivírus e ao cache global de fios continuamente.

Boa pegada! Eu me esqueci totalmente disso, pois já tenho c:\src na lista de permissões em meus computadores.

@OshotOkill - Você gostaria de enviar uma solicitação de pull adicionando uma observação sobre aplicativos antivírus ao site, nas instruções de instalação do Windows? Aqui está o arquivo que você precisa editar: https://github.com/yarnpkg/website/blob/master/en/docs/_installations/windows.md (você pode editá-lo diretamente no Github). Seria apreciado 😄

Eu não era tão meticuloso quanto @OshotOkill , mas adicionei exceções para minha fonte e minha pasta de instalação de node e, em seguida, isentei especificamente os binários de yarn, npm e node e agora meu tempo de instalação no Windows caiu para 50 segundos de 122 segundos .

@ Daniel15 PR está pronto. Peça desculpas pelo meu pobre inglês.

PR foi mesclado. Feche este problema.

Isso ainda é dolorosamente lento no Windows, desativando até mesmo o antivírus e o defensor do Windows. Não acho que seja apenas um problema de ambiente (como esta solução antivírus), mas parece que o yarn tenta copiar todos os arquivos, 1 por 1, mesmo que você instale alguma dependência não relacionada.

Por que não apenas excluir / copiar os arquivos que precisam ser alterados? Se eu tivesse webpack instalado e não fosse modificado quando instalei rimraf , ele não deveria ter que ser copiado novamente do cache para a pasta node_modules local.

Eu criei um artigo StackOverflow sobre isso também: http://stackoverflow.com/questions/40566222/yarn-5x-slower-on-windows

A propósito, em meus benchmarks do Ubuntu (com inicialização dupla), eu estava usando o mesmo drive NTFS que o Windows normalmente roda; e ainda é rápido lá.

Adicionar node.exe às exclusões do Windows Defender me deu um grande aumento de desempenho http://126kr.com/article/1884rsed7l

Definitivamente vou experimentar!

Pareceu melhorar a velocidade um pouco 212 -> 170 segundos
Então, parece ajudar, mas ainda pode ser melhorado, porque ainda é mais de 3x mais lento do que no Linux

Outro problema que observei - o serviço de indexação no Windows tenta indexar todos os arquivos em node_modules.
Eu realmente não preciso disso, então desativei http://www.softwareok.com/?seite=faq-Windows-10&faq=53 e ganhei outro aumento de desempenho.

Meu windows não está configurado para indexar o caminho em questão, então isso ainda não resolve o problema.

Portanto, para resumir, existem 4 maneiras de melhorar o desempenho:

• Lista de permissões da pasta do projeto do AV
• White enquanto o diretório de cache do Yarn ((% LocalAppData% Yarn)) do AV
• Adicionando node.exe às exclusões do Windows Defender
• Desativando o serviço de indexação no Windows na pasta node_modules

@Altiano sim, mas ainda não é o suficiente para obter desempenho nem perto de Mac / Linux

Parece meio incompleto que você teria que desativar o AV ou a indexação nos diretórios para tornar o fio tão rápido ou mais rápido que o npm. Afinal, você não precisa fazer isso para o npm. Decidi dar uma chance ao yarn porque ele afirmava ser rápido e as instalações offline tornavam a codificação sem uma conexão de rede uma coisa plausível. Não há como otimizar a vinculação?

De acordo com alguns problemas que se relacionam aqui e os comentários acima, gostaria de reabrir esse problema para reunir algumas outras soluções.

Pessoalmente, sugiro listar as configurações de hardware sobre sua máquina de teste e fazer upload de algumas fotos relacionadas. Pode haver muitos outros elementos irrelevantes que fazem uma grande diferença entre as plataformas ao invés do próprio Yarn, ou seja, o desempenho de benchmark do SSD em um MacBook é geralmente muito melhor do que uma máquina Windows.

@OshotOkill como eu disse antes, eu obtive um desempenho 3,5x mais lento no Windows vs Linux com os índices e o Windows Defender desativados para os diretórios relevantes, no mesmo PC normal na mesma unidade _ntfs_. O fato de que mesmo no NTFS é muito mais rápido no Linux diz muito, eu acho.

Vamos descobrir o motivo disso.
Poderia ser o NTFS funcionando mais lentamente em um grande número de arquivos sendo movidos durante a instalação?

Alguém pode compartilhar uma maneira de reproduzir isso em uma única máquina?
Por exemplo, um determinado package.json instalado em um laptop Windows leva X segundos, mas é executado no VirtualBox Ubuntu X-20% segundos.

@amcsi @bestander Como costuma acontecer, EXT4 / XFS são mais rápidos ao copiar grandes quantidades de arquivos pequenos. No entanto, o NTFS não é muito mais lento. Limpei o cache e testei novamente usando a versão mais recente do Yarn and Node (0.19.1 e 7.5.0):

O resultado é muito próximo de um MacBook ao instalar react-native . Tudo o que fiz foi apenas colocar na lista de permissões as pastas relacionadas e o processo Node.exe.

Eu mesmo estava tendo esse problema até colocar na lista de permissões os processos node.exe e yarn.exe no Windows Defender, junto com o diretório do meu projeto. Eu não desativei a indexação de pesquisa, nem coloquei na lista de permissões o diretório de cache do Yarn. Os tempos de instalação foram de mais de 190 segundos em um projeto de médio porte a cerca de 25 segundos em um cache limpo. Minha máquina Ubuntu é um pouco mais rápida do que isso, mas apenas por 5-10 segundos.

Configuração de hardware:
512gb SSD
12gb RAM
CPU AMD FX-8350 de 8 núcleos a 4,01 ghz
Windows 10 de 64 bits, compilação 14986.

Acabei de fazer alguns testes rápidos em meu próprio sistema. Eu tenho o Linux Mint e o Windows 10 com inicialização dupla no mesmo SSD. Limpei meu cache de fios, excluí node_modules e executei yarn neste projeto vue .

Linux Mint: _12.22s_

Windows 10 (sem lista branca): _64.32s_

Windows 10 (com lista branca): _42.58s_

Estas foram as exclusões do Windows Defender que eu tinha ativo:

Embora a lista branca pareça ter um efeito significativo, ainda não chegou perto de corresponder à velocidade do Linux.

EDIT: Para @bestander , aqui estão meus dados normalizados:

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

@keawade Eu tinha 26.48s para instalar seu projeto de um cache limpo e 13.58s para instalá-lo com o cache.

Estou apenas brincando aqui, estou usando o Yarn.cmd do instalador MSI e parece que você está usando o Yarn instalado do NPM. Eu me pergunto se talvez haja uma discrepância entre eles?

@nozzlegear Embora isso seja possível, acho que é menos provável do que devido a conexões de internet diferentes.

Precisamos eliminar a rede disso.
Atualmente, posso testar este repositório no Windows 10 mais recente com o recurso "Linux no Windows" habilitado.
A instalação via CMD e Bash com caches principais leva cerca de 27-29 segundos em um processador i7 de 2 núcleos.

@keawade , você pode executar o mesmo teste com node_modules removido, mas caches no lugar?

Ainda não consigo instalar um segundo sistema operacional no dispositivo que tenho.
Alguém pode verificar se a execução do Windows e do Linux em uma caixa virtual dá resultados diferentes?

Criei o mestre atual com carimbos de data / hora https://github.com/yarnpkg/yarn/releases/download/v0.21.0-pre/yarn-0.21.0-0.js

Você pode usá-lo para instalar com a bandeira --verbose ?

Por exemplo

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

Deve fornecer carimbos de data / hora para todas as operações FS

Dados sem limpar caches

_Nota: Estes dados estão sendo registrados em um sistema com inicialização dupla. Todo o hardware é idêntico para esses testes._

| OS | Tempo médio | Normalizado |
| ----------------------------- | ---------- | -------- ---- |
| Linux Mint | 5.598s | 1,00000 |
| Windows 10 (com lista branca) | 12.119s | 2,16488 |
| Windows 10 (sem lista branca) | 31.578s | 5,64094 |

_Avg Time é a média em um conjunto de 10 testes_

Dados brutos do Linux Mint

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

Dados brutos do Windows 10

Com Lista Branca

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

Sem Lista Branca

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

Metodologia

Usei este script PowerShell para gerar todos os dados mostrados aqui. O script clona esse repo e executa 10 iterações do comando yarn , excluindo node_modules após cada iteração.

@bestander , atualizei o post anterior com os dados do Windows.

Ótimo, obrigado por mais dados.
Você pode tentar a versão --verbose com yarn.js com timestamps para ambos os sistemas operacionais?
Isso nos daria uma boa ideia de onde o tempo é gasto.

Uau, isso é muito log! Você quer 10 execuções para cada combinação de SO / lista branca ou uma para cada uma é boa o suficiente?

@bestander Aqui está! Um de cada.

Nota lateral: Acontece que se você tentar fazer upload de ~ 30 MB de texto bruto para uma única coleção de essência, você obterá um erro nginx 405. 😆

~ Linux Mint ~
~ Windows 10 com exclusões e limpo ~
~ Windows 10 com exclusões e sem _clean_ ~
~ Windows 10 com limpo e sem _exclusões_ ~
~ Windows 10 sem _exclusões_ e _sem_ limpo ~

VerboseLogs.tar.gz

EDIT: Removendo gists e enviando os arquivos compactados.

Acontece que se você tentar fazer upload de ~ 30 MB de texto bruto para uma única coleção de essência, obterá um erro nginx 405. 😆

Você pode compactar os arquivos (bzip2 ou 7-Zip) e anexá-los aqui ... O texto simples é compactado muito bem :)

@ Daniel15 Bom ponto, aqui estão os arquivos compactados: VerboseLogs.tar.gz

Uma corrida estaria bem :)

Eu comparei LinuxMint.txt com Windows10NoClean.txt

Linux:

• fase de ligação começa em 1,156 segundos
• todas as pastas dentro de node_modules criados em 1.968
• último arquivo copiado em 3,873 segundos
• as compilações são feitas em mais 3 segundos

janelas

• fase de ligação começa em 2.779 segundos
• todas as pastas dentro de node_modules criados em 4,83
• último arquivo copiado em 32.853
• as compilações são feitas em mais 3 segundos

Obviamente, o log detalhado afeta o tempo de execução no Windows (12 -> 35 segundos), mas não no Linux (os mesmos 6 segundos).

Pelos benchmarks que encontrei na internet, o Linux EXT3 FS geralmente supera o NTFS quando muitos arquivos são copiados.
Eu me pergunto se esse é o limite que temos que enfrentar.

@keawade , as velocidades são diferentes ao usar o npm @ 3 no Windows e no Linux?

Algumas ideias:

• O Windows pode ser ruim na cópia simultânea, nós copiamos arquivos em 4 threads. Talvez com um único segmento?
• Talvez use robocopy wrapper no Windows https://github.com/mikeobrien/node-robocopy
• usamos readstream.pipe.writestream para copiar arquivos, talvez seja ineficiente no Windows

Se você estiver ansioso para experimentar, substitua 4 por 1 em https://github.com/yarnpkg/yarn/blob/master/src/util/fs.js#L322 e veja se a cópia de thread único fica mais rápida no Windows

Testes de linha

A pedido de @bestander , yarnpkg/yarn e modifiquei a linha 322 de src/util/fs.js , substituindo 4 por 1 . Em seguida, usei yarn run build para construir o projeto e executei 10 testes com essa construção usando yarn.cmd que foi compilado pela construção. Esses são os resultados.

| | Tempo médio | Normalizado |
| ---------------------------- | ---------- | --------- --- |
| Windows 10 (com lista branca) | 12.119s | 1,00000 |
| Tópico de cópia única | 16.927s | 1,39673 |
| Tópico de cópia única + Limpar | 42.268s | 3,48775 |

_Avg Time é a média em um conjunto de 10 testes_

Parece que usar apenas um único thread para copiar os arquivos resulta em tempos de instalação um pouco mais lentos.

Dados não tratados

Windows 10 (c / lista branca)

Esses dados são de um teste anterior

Tópico de cópia única

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

Tópico de Cópia Única + Limpar

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

Obrigado, @keawade.
Você pode verificar minha suposição de que o NTFS pode ser mais lento para copiar um grande número de arquivos do que o Linux FS?

Meça a cópia por meio de node_modules totalmente instalados no terminal para outro local no Linux Mint e no Windows 10, por favor.

Também é necessário testar a cópia usando robocopy com a opção /mt (cópias multithread)

Eu também gostaria de relatar um bug possivelmente relatado, em que cada yarn add ou yarn remove leva cerca de 30-40 minutos. Aparentemente, ele copia TODAS as dependências novamente e, como estou no Windows, isso leva muito tempo. Veja o problema vinculado:

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

@kumarharsh # 2458 Levei 28s para terminar a instalação.

Também devo mencionar que não se esqueça de colocar na lista de permissões as pastas do projeto, não apenas o cache.

Copiar testes

Usei esse script para executar 10 iterações de cópias no Linux Mint e no Windows 10. Copiei este repositório após executar yarn no diretório. Esses são meus resultados.

| OS | Tempo médio | Normalizado |
| ------------ | ------------ | ------------ |
| Linux Mint | 1527,4620 | 1,00000 |
| Windows 10 | 53676.3155 | 35.14085 |

Essa diferença de tempo é louca. Essas cópias foram feitas copiando arquivos de um local para outro no mesmo SSD_.

Dados não tratados

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

Não tenho tempo agora para testar a robocópia, mas posso obter os dados esta noite depois do trabalho.

Teste Robocopy

Usei esse script para executar 10 iterações de cópias no Linux Mint e no Windows 10. Copiei este repositório após executar yarn no diretório. Esses são meus resultados.

| OS | Tempo médio | Normalizado |
| ----------------------- | ------------ | ------------ |
| Linux Mint | 1527,4620 | 1,00000 |
| Windows 10 | 53676.3155 | 35.14085 |
| Windows 10 (Robocopy) | 58089.7457 | 38.03024 |

Robocopy teve um desempenho um pouco pior do que uma cópia normal.

Dados não tratados

Os valores do Linux Mint e do Windows 10 são dos testes anteriores

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

@keawade , você pode verificar se a indexação de arquivos e o Defender não interferem na cópia?
Afaik ele pode se envolver até mesmo para um comando cp.

Verifique o que está ativo no Gerenciador de Tarefas quando a cópia é feita.
E talvez apenas desligue esses serviços para um teste

Testes de Indexação e Defensor

Realizei testes nas seguintes condições:

• Com o Windows Defender desativado
• Com serviço de indexação do Windows desativado
• Com _both_ desativado o Windows Defender e o serviço de indexação do Windows
• Com _both_ desativado o Windows Defender e o serviço de Indexação do Windows _e_ limpar o cache do Yarn

Para desativar o Windows Defender, desativei Real-time protection no painel de configurações do

Para desativar a indexação do Windows, parei o serviço Windows Search no painel de controle de Serviços .

_Nota: Quando o Windows Defender foi ativado, nenhuma exclusão foi listada_

Usei este script para executar 10 iterações de cópias no Linux Mint e no Windows 10. Copiei este repositório depois de executar yarn no diretório. Esses são meus resultados.

Resumo

Parece que, embora a indexação do Windows (serviço de pesquisa) tenha um impacto nas operações de cópia e no Yarn, o maior impacto vem do Windows Defender.

Copiando

| OS | Tempo médio | Normalizado |
| -------------------------------------------- | ---- -------- | ------------ |
| Linux Mint | 1527,4620 | 1,00000 |
| Windows 10 (sem defesa) | 7301.4307 | 4.78011 |
| Windows 10 (sem indexação) | 10307.0794 | 6,74787 |
| Windows 10 (sem defesa, sem indexação) | 7044.1393 | 4,61166 |
| Windows 10 Robo (sem defesa, sem indexação) | 10094.8358 | 6,60889 |

Indexação Desativar totalmente a indexação e o antivírus oferece um grande aumento no desempenho ao copiar arquivos.

Fio

Como os resultados acima foram tão pronunciados, concluí que provavelmente poderíamos usar dados sobre o desempenho do Yarn nessas condições também.

Usei este script para executar 10 iterações de yarn no Linux Mint e no Windows 10. Clonei este repo e executei yarn no diretório.

| OS | Tempo médio | Normalizado |
| --------------------------------------------- | --- ------- | ------------ |
| Linux Mint | 5,5980 | 1,00000 |
| Windows 10 (sem defesa) | 16,5450 | 2,95552 |
| Windows 10 (sem indexação) | 38,5170 | 6,88049 |
| Windows 10 (sem defesa, sem indexação) | 16,8490 | 3.00982 |
| Windows 10 Clean (sem defesa, sem indexação) | 30,7730 | 5,49714 |

Dados não tratados

Os valores do Linux Mint são dos testes anteriores .

Copiar Item do Windows 10

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

Robocopy do Windows 10

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

Windows 10 Yarn

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

Windows 10 Yarn Clean

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

Indexação do Windows 10 Yarn desativada

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

Indexação de cópia do Windows 10 desativada

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

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

Cópia do Windows 10 do Windows Defender desativado

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

Essa é uma pesquisa sólida, @keawade , obrigado por compartilhar todos os dados.
Os dados sugerem que o desempenho do sistema de arquivos bruto é o gargalo para as instalações do yarn no Windows.
Não tenho certeza se o Yarn pode fazer alguma coisa aqui, a menos que haja algum comando de cópia inteligente que contorne a limitação

@keawade, obrigado por ter @bestander poderia ser assim desdemamãe O npm não enfrenta os mesmos problemas ao copiar (digitalização perpétua), talvez o fio não esteja assinado? Pode ser que o Windows Defender não confie em fios no mesmo nível que npm. Apenas um pensamento...

@kumarharsh , vamos precisar medir a diferença entre npm e yarn então.
Talvez o npm esteja copiando menos arquivos (o içamento do Yarn não é otimizado para a menor árvore node_modules).
E seria ótimo se pudéssemos colocar fios na lista de permissões automaticamente por meio do instalador.

talvez o fio não esteja assinado? Pode ser que o Windows Defender não confie em fios no mesmo nível que npm.

Não acho que os scripts possam ser assinados (com exceção dos scripts do PowerShell que oferecem suporte a assinaturas Authenticode), então não acho que Yarn e npm seriam diferentes nesse aspecto. O instalador do Yarn é assinado com Authenticode, assim como o do npm.

E seria ótimo se pudéssemos colocar fios na lista de permissões automaticamente por meio do instalador.

Sinto que tocar automaticamente em uma lista de permissões de varredura de vírus resultaria em varredores de vírus marcando o instalador como malware. Parece uma coisa arriscada de se fazer. Talvez pudéssemos colocar automaticamente o diretório na lista negra do indexador de pesquisa.

@keawade Eu testei o robocopy com as opções /E /MT (cópias multithread).

| Método de cópia | Tempo médio |
| ---------------------- | ---------- |
| Copy-Item -Recurse | 20219 |
| Robocópia /E | 26652 |
| Robocópia /E /MT | 9043 |

Dados brutos (windows 10)

Copy-Item -Recurse

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

Robocópia /E

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

Robocópia /E /MT

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

Não acho que os scripts possam ser assinados (com exceção dos scripts do PowerShell que oferecem suporte a assinaturas Authenticode), então não acho que Yarn e npm seriam diferentes nesse aspecto. O instalador do Yarn é assinado com Authenticode, assim como o do npm.

Parece razoável.
Podemos verificar isso?
Se estiver executando npm install , o Indexer e o Defender aparecem no Gerenciador de Tarefas?

Defensor NPM e testes de indexação

Registrei o tempo que levou para executar npm install neste repo sob o mesmo conjunto de condições que os testes de indexação e defesa para Yarn e métodos de cópia do Windows.

| OS | Tempo médio | Normalizado |
| --------------------------------------------- | --- ------- | ------------ |
| Linux Mint (Yarn) | 5,5980 | 1,00000 |
| Linux Mint (NPM) | 28,9793 | 5,17672 |
| Windows 10 (sem defesa) | 42,6296 | 7,61514 |
| Windows 10 (sem indexação) | 53.8791 | 9,62470 |
| Windows 10 (sem defesa, sem indexação) | 37,9727 | 6,78326 |
| Windows 10 (sem alterações) | 58,5047 | 10,45100 |

Resumo

Parece que o NPM também é afetado pelo Windows Defender.

Dados não tratados

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 com Windows Defender desativado

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

NPM com indexação do Windows desativada

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

NPM com Windows Defender e indexação do Windows desativada

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

Suponho que precisaremos contornar a limitação de o Windows ser mais lento no IO de disco, reduzindo o número de operações IO em geral e educando as pessoas sobre Indexação e Defender.
Substituir cópia por robocópia também parece uma boa ideia.

reduzindo o número de operações de IO em geral

Essa é uma boa ideia em geral e ajudará no desempenho em qualquer lugar. Também pode ser muito benéfico para pessoas que criam em servidores com discos rígidos lentos.

Ansioso por um PR para substituir a tubulação de streams fs por uma cópia robótica no Windows aqui .

- Atualização
No entanto, isso pode não ser ideal porque copyBulk tem alguma lógica extra, como exclusões, que podem não ser traduzidas em um único comando de robocopy.

Alguém sabe por que isso acontece comigo (todas as vezes)?

Para expandir a postagem:
Em minha máquina Windows - cada yarn add ou yarn rm re-copia todos os módulos de nó em meu projeto, o que faz com que cada mudança em package.json leve um tempo terrivelmente longo para ser concluída. Essa barra de progresso para 160 mil dependências vem sempre e rasteja como uma tartaruga encalhada em um campo de petróleo. Observe os tempos da operação yarn rm paper que acabei de fazer antes dos yarn add - 1000 segundos!

E cancelar uma dessas add/rm operações não é possível, pois bagunça a pasta node_modules e qualquer yarn install / npm install / rm -r node_modules/ e começando tudo de novo. Esse único motivo é doloroso o suficiente para me impedir de usar a instalação do fio.

Eu acho que você elevou mal os node_modules, este bug será corrigido em # 2676

Com a introdução do @bestander de links físicos dentro # 2620 (que funciona bem no Windows 7 sem privilégios de administrador), os meus tempos totais de instalação e node_modules/ tamanho, caiu.

Sem hardlinking:

Done in 167.76s.

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

du -sh node_modules/
216M    node_modules/

Com hardlinking:

Done in 58.07s.

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

du -sh node_modules/
189M    node_modules/

Espere pelo 0.21.1, ele terá a correção do @kittens para içar.
Deve ser ainda mais rápido

Na quarta-feira, 15 de fevereiro de 2017 às 20:04, Hutson Betts [email protected] escreveu:

Com a introdução de @bestander https://github.com/bestander de
hardlinking em # 2620 https://github.com/yarnpkg/yarn/pull/2620 (que
funciona bem no Windows 7 sem privilégios de administrador), meu geral
tempos de instalação e node_modules / size eliminados.

Sem hardlinking:

Feito em 167,76s.

2m49.633s reais
usuário 0m0.229s
sys 0m1.368s

du -sh node_modules /
216M node_modules /

Com hardlinking:

Feito em 58.07s.

0m59.967s reais
usuário 0m0.183s
sys 0m1.369s

du -sh node_modules /
189M node_modules /

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/yarnpkg/yarn/issues/990#issuecomment-280122923 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/ACBdWAEghXfPo4bX9mN0hV8l8YaH2rmlks5rc1pigaJpZM4KVwpA
.

Estou no Win7 / w Yarn v0.21.3

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

Tive que esperar esse período de tempo adicionando qualquer novo pacote com yarn add ...
Defensor desligado
Indexação desativada

Tenha algum outro antivírus em execução, então apenas siga os passos mencionados acima por @Altiano

Lista de permissões da pasta do projeto do AV
White enquanto o diretório de cache do Yarn ((% LocalAppData% Yarn)) do AV

Irá atualizar neste

@kuncevic , qual seria o tempo de instalação limpa para o projeto?
Qual é o tamanho da pasta node_modules nos arquivos?
Como ele se compara ao npm install?

@bestander, esse é o mesmo problema comigo. Qualquer yarn add ou yarn remove leva o mesmo tempo - aproximadamente, mesmo após as correções de içamento de @kittens .

Sempre que isso acontece:

1. Primeiro, o Fetching packages é executado (leva cerca de 30s):
   
2. Em seguida, a vinculação de dependências pausa por cerca de 1 ou 2 minutos.
   
3. Em seguida, ele continua com a próxima etapa e instala (?) 63k arquivos novamente.
   

Como eu disse, isso acontece toda vez que executo yarn add ou yarn remove . Não importa se a dependência que estou instalando depende de qualquer outra dependência. Um simples npm install para instalar uma nova dependência ou atualizar uma existente leva uma fração desse tempo. As coisas melhoraram 2x com as correções de içamento do @kittens , mas ainda assim o tempo gasto é muito grande.

@bestander se você quiser um caso reproduzível, clone este repositório: https://github.com/kumarharsh/yarn-bug e execute yarn install e, em seguida, yarn add react-helmet .

Yarn está preservando o determinismo toda vez que executa add / remove, então ele precisa verificar se alguma dependência foi içada para a raiz de node_modules quando as dependências mudam.
É por isso que ele executa a fase de vinculação completa.

Buscando dependências - baixe, você não pode otimizá-lo.
Primeira fase de vinculação (1561 operações) - cria todas as pastas para todas as dependências.
Segunda fase de vinculação (operações de 63K) - copia os arquivos do cache para node_modues.

O Yarn otimiza as operações de cópia de arquivo verificando se os arquivos são os mesmos antes de fazer a cópia.
Talvez queiramos traçar um perfil melhor desta área e ver se podemos diminuir o número de IO desnecessários.
Talvez no Windows copiar fosse mais rápido do que verificar?

E o npm, quão rápido ele faz uma instalação limpa?

Uma instalação limpa para npm ( npm install ) leva 552301.1944ms .
Instalar uma dependência adicional ( npm install weird ) requer 57023.7593ms . (A maior parte desse tempo é desperdiçado em papéis tentando instalar o canvas como um dep - mas desta vez seria comum para npm e yarn)

Uma instalação limpa para fios ( yarn install ) leva 612698.4915ms .
Instalar uma dependência adicional ( yarn add weird ) requer 495633.0307ms .

npm version 3.10.9
yarn version 0.21.3

@bestander @kumarharsh Yarn não otimiza as operações de cópia de arquivo no Windows devido a um bug libuv / nodejs (Veja # 2958 para uma possível correção no código do yarn) que não está presente no nó 7.1+ para que você possa obter seu segundo comando ( yarn add ) para ser muito mais rápido apenas atualizando o nó.

Usar a operação de cópia de arquivo do Windows é um pouco mais rápido do que usar a API do node para copiar arquivos também (Veja # 2960 para um PR potencial) e otimizaria yarn install um pouco, mas não sei se iria egalizar com npm (não testei)

Apenas atualizado para 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.

No entanto, ao fazer yarn add rimraf foi concluído em 20.52s. mas por que yarn install depois de remover node_modules demorando tanto?

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 É bom ver que a atualização do nó funciona para yarn add :)

Em relação ao vazio node_modules uma boa coisa a fazer é medir quanto é devido ao fio e quanto é devido ao FileSystem, Disco rígido e antivírus.
O que eu fiz para testar isso foi copiar o node_module completo (conforme gerado pelo fio, não npm) de material2 em algum lugar no cache do fio:

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

E então para cada teste eu limpei node_modules e executei yarn install , npm install ou xcopy da pasta criada anteriormente:

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

E levou o total de segundos.

Resultados

Aqui estão os resultados em 3 PCs

• 🏠 PC doméstico: Samsung 950 Pro NVMe, ESET Nod32
• 🏢 PC de trabalho: Samsung 850 EVO SATA, TrendMicro OfficeScan que não consigo desativar
• 🍎 MacBook pro: versão 2015, em macos, sem antivírus

|| yarn 🏠 | npm 🏠 | xcopy 🏠 | yarn 🏢 | npm 🏢 | xcopy 🏢 | yarn 🍎 | npm 🍎
| - | - | - | - | - | - | - | - | -
| AV desativado | 34s | 90s | 23s | - | - | - | 32s | 92s
| AV Exclude cache & code | 38s | 104s | 29s | - | - | - | - | -
| Av Exclude cache only | 43s | - | 31s | - | - | - | - | -
| Av full | 48s | 122s | 32s | 100s | 274s | 236s | - | -

Cada vez que o AV era habilitado, ele estava no topo da tabela de CPU durante yarn install ou xcopy (No meu PC doméstico, 30% da CPU total foi tirada no máximo, mas no meu PC do trabalho preencheu um núcleo para xcopy e todos os meus núcleos para fio)
O xcopy é mais lento no meu PC de trabalho do que o yarn, eu suspeito porque ele não copia arquivos em paralelo enquanto o yarn faz (Isso não deveria importar para as operações de IO, mas o AV está tornando-o uma operação de CPU & xcopy não foi escrito lute contra tanta estupidez 😄)

Em conclusão

• yarn é mais rápido do que npm e pode até ser mais rápido do que xcopy quando o AV faz a cópia do arquivo limite da CPU
• O Windows em um bom SSD não é realmente mais lento que um MacBook Pro 2015 (que já tem um bom SSD), mesmo que seja difícil de comparar, pois não são exatamente os mesmos pacotes instalados e nem todos os scripts de pós-instalação fazem a mesma coisa
• Algumas mudanças podem ser feitas no yarn para contornar isso (vincular arquivos simbólicos?), Mas essencialmente lidar com muitos arquivos pequenos é lento
• No Windows AV pode torná-lo mais lento , o meu adiciona 30% quando ativado nas pastas de origem e destino 😞
• Os AVs corporativos podem ser muito mais lentos do que os AVs domésticos e eliminar o desempenho o suficiente para que qualquer operação de cópia seja dolorosa (quando faz com que a operação naturalmente ligada por IO seja limitada pela CPU) 😡

Adicionar npm, pastas de cache de yarn e node.exe à lista de exclusão do defensor seria o suficiente, é claro que tudo isso não pode estar em pastas indexadas. Agora yarn add / rm leva 7 segundos

Obrigado a todos, uma otimização significativa para o Windows chegou a 0,24 https://github.com/yarnpkg/yarn/pull/3234#issuecomment -297552326

@vbfox Você pode adicionar números de versão para npm e yarn em seu benchmark?

isso ainda é um pedaço de merda para MacOSX

Ainda estou passando por momentos de instalação loucos. yarn add parece instalar e vincular tudo (todos os itens em package.json , ~ 30k dependências) o tempo todo.

Versões Linux:

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

Versões 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

Eu tenho duas (e meia) perguntas:

1. Qual é a solução aceita para o problema neste tópico? Era o nº 3234 ou o ajuste do Windows Defender?

   • Se a solução foi ajustar o Windows Defender, há uma descrição completa do que fazer em algum lugar?

2. Meu problema está realmente relacionado a este tópico ou devo criar um novo?

Obrigado por levantar um novo problema, responderei lá

Já faz quase uma hora e estou aguardando esse comando para finalizar o processo. Eu segui os pontos acima mencionados por @Altiano mas nada funciona

temos alguma alternativa para isso? como posso usar npm i -g . , funcionará da mesma maneira ou terei que fazer algumas alterações porque este código usa yarn workspace

Então, finalmente, depois de lutar por 2-3 horas, tive que usar npm i -g . vez de yarn global add file:. . npm funcionou como um encanto