Yarn: Windows에 대한 큰 최적화 필요

+1

안녕하세요 @OshotOkill! Yarn을 사용해 주셔서 감사합니다. Cygwin 또는 WSL ( "Windows의 Ubuntu에서 Bash")을 사용하고 있습니까? 둘 다 디스크 IO 성능이 상당히 나쁜 것으로 알려져 있습니다.

또한 React Native에는 엄청난 수의 파일이 있으므로 node_modules 로 복사하는 것이 매우 느리고 Windows의 많은 작은 파일에 대한 디스크 IO는 일반적으로 Mac OS보다 느립니다 (Linux ext4보다 느림). 이 시나리오에서 성능을 향상시킬 하드 링크 (# 499)를 실험 할 작업이 있습니다.

캐시 없음 및 동일한 네트워크 환경

Yarn의 주요 개선점은 웜 캐시가있는 경우 (즉, 패키지를 한 번 이상 설치 한 후)이지만 React Native를 사용하면 엄청난 수의 파일도 일부 속도 저하의 원인이됩니다.

@ Daniel15 아니요, Cygwin / MinGW / MSYS2 또는 WSL을 사용하지 않습니다 (후자는 결절 버그로 인해 실패 함).

귀하의 설명에 따르면 문제가 파일 시스템 (NTFS)으로 인한 것이라고 생각할 수 있습니다. 웜 캐시가 존재하더라도 복사 프로세스는 여전히 MacOS보다 훨씬 느리게 실행됩니다.

개발팀이 최대한 빨리 해결책을 찾을 수 있기를 바랍니다. 감사.

나는 똑같이보고있다.

설치하고 node_modules를 지우고 설치하십시오.

MacBookPro는 17 초, Windows 컴퓨터는 122 초 걸립니다.

누군가는 이것이 안티 바이러스 소프트웨어 스캐닝 node_modules 및 글로벌 얀 캐시와 관련이있을 수 있다고 지적했습니다. 해당 폴더에 대해 비활성화 할 수 있습니까?

@cpojer 나는 그들이

기본값 : 128.08s

캐시 폴더 스캔 없음 : 104.43s

프로젝트 폴더 스캔 없음 : 78.28s

캐시 폴더 및 프로젝트 폴더 스캔 없음 : 53.48 초

10 초 이상 Mac보다 느리지 만 상당한 향상이 있습니다.

이것은 내가 생각하는 공식 문서에서 알려야합니다.

누군가는 이것이 안티 바이러스 소프트웨어 스캐닝 node_modules 및 글로벌 얀 캐시와 관련이있을 수 있다고 지적했습니다.

잘 잡아! 내 컴퓨터에 이미 c:\src 화이트리스트가 등록되어 있기 때문에 이것을 완전히 잊었습니다.

@OshotOkill -Windows 설치 지침에서 웹 사이트에 바이러스 백신 앱에 대한 메모를 추가하는 풀 요청을 제출 하시겠습니까? 편집해야 할 파일은 다음과 같습니다. https://github.com/yarnpkg/website/blob/master/en/docs/_installations/windows.md(Github에서 직접 편집 할 수 있음). 감사하겠습니다 😄

@OshotOkill 만큼 세심하지는 않았지만 소스 및 노드 설치 폴더에 대한 예외를 추가 한 다음 특히 yarn, npm 및 노드 바이너리를 제외했으며 이제 Windows에서의 새 설치 시간이 122 초에서 50 초로 줄었습니다. .

@ Daniel15 PR 이 준비되었습니다. 저의 가난한 영어에 대해 사과드립니다.

PR이 병합되었습니다. 이 문제를 닫습니다.

이것은 바이러스 백신 및 Windows 방어기를 비활성화하는 경우에도 Windows에서 여전히 고통스럽게 느립니다. 나는 이것이 단지 환경 ​​문제 (이 안티 바이러스 솔루션과 같은)라고 생각하지 않지만, 관련없는 종속성을 설치하더라도 yarn이 모든 파일을 일대일로 복사하려고 시도하는 것처럼 보입니다.

변경해야하는 파일을 삭제 / 복사하지 않는 이유는 무엇입니까? webpack 설치했고 rimraf 설치할 때 수정되지 않은 경우 캐시에서 로컬 node_modules 폴더로 다시 복사 할 필요가 없습니다.

이것에 대한 StackOverflow 기사도 만들었습니다. http://stackoverflow.com/questions/40566222/yarn-5x-slower-on-windows

그건 그렇고, 내 (이중 부팅) Ubuntu 벤치 마크에서 나는 Windows가 일반적으로 실행되는 것과 동일한 NTFS 드라이브를 사용하고있었습니다. 여전히 빠릅니다.

Windows Defender 제외에 node.exe 을 추가하면 성능이 크게 향상되었습니다. http://126kr.com/article/1884rsed7l

나는 이것을 확실히 시도 할 것이다!

속도가 약간 향상되는 것 같습니다 212-> 170 초
도움이되는 것 같지만 여전히 개선 될 수 있습니다. Linux보다 여전히 3 배 이상 느립니다.

내가 발견 한 또 다른 문제-Windows의 인덱싱 서비스는 node_modules의 모든 파일을 인덱싱하려고합니다.
실제로 필요하지 않으므로 http://www.softwareok.com/?seite=faq-Windows-10&faq=53을 비활성화하고 또 다른 성능 향상을 얻었습니다.

내 창이 문제의 경로를 인덱싱하도록 설정되어 있지 않으므로 여전히 문제가 해결되지 않습니다.

요약하면 성능을 향상시키는 4 가지 방법이 있습니다.

• AV에서 프로젝트 폴더 화이트리스트
• AV에서 Yarn 캐시 디렉토리 ((% LocalAppData % Yarn))를 Whiteilst
• Windows Defender 제외에 node.exe 추가
• Windows에서 node_modules 폴더의 인덱싱 서비스 비활성화

@Altiano 예,하지만 여전히 Mac / Linux에 가까운 성능을 얻기에는 충분하지 않습니다.

얀을 npm보다 빠르거나 빠르게 만들려면 AV 또는 디렉토리 색인 생성을 비활성화해야 할 것 같습니다. 결국 npm에 대해이 작업을 수행 할 필요가 없습니다. 나는 그것이 빠르고 오프라인 설치가 네트워크 연결없이 코딩을 그럴듯하게 만들었다 고 말했기 때문에 yarn에게 기회를 주기로 결정했습니다. 연결을 최적화 할 방법이 없습니까?

여기와 관련된 몇 가지 문제와 위의 의견에 따라 다른 해결책을 모으기 위해이 문제를 다시 열고 싶습니다.

개인적으로 테스트 머신에 대한 하드웨어 구성을 나열하고 관련 사진을 업로드하는 것이 좋습니다. Yarn 자체보다는 플랫폼간에 큰 차이를 만드는 다른 관련없는 요소가 많이있을 수 있습니다. 즉, MacBook에서 SSD의 벤치 마크 성능은 일반적으로 Windows 시스템보다 훨씬 좋습니다.

@OshotOkill 이전에 말했듯이, 동일한 _ntfs_ 드라이브의 동일한 일반 PC에서 관련 디렉토리에 대해 인덱스 및 Windows 방어기가 비활성화 된 Linux 대 Windows에서 3.5 배 더 느린 성능을 얻었습니다. ntfs에서도 Linux에서 훨씬 빠르다는 것이 제 생각에 많이 말합니다.

그 이유를 알아 봅시다.
설치 중에 이동되는 많은 파일에서 NTFS가 느리게 작동 할 수 있습니까?

누구든지 단일 시스템에서이를 재현하는 방법을 공유 할 수 있습니까?
예를 들어 Windows 랩톱에 설치된 특정 package.json은 X 초가 걸리지 만 VirtualBox Ubuntu X-20 % 초에서 실행됩니다.

@amcsi @bestander 종종 그렇듯이 EXT4 / XFS는 많은 양의 작은 파일을 복사하는 동안 더 빠릅니다. 그러나 NTFS는 그다지 느리지 않습니다. 방금 캐시를 정리하고 최신 버전의 Yarn 및 Node (0.19.1 및 7.5.0)를 사용하여 다시 테스트했습니다.

결과는 react-native 를) 설치하는 동안 MacBook에 정말 가깝습니다. 내가 한 것은 관련 폴더와 Node.exe 프로세스를 허용 목록에 추가하는 것뿐이었습니다.

프로젝트 디렉터리와 함께 Windows Defender의 node.exe 및 yarn.exe 프로세스를 화이트리스트에 올릴 때까지이 문제가 발생했습니다. 검색 인덱싱을 전혀 비활성화하지 않았으며 Yarn 캐시 디렉터리를 허용 목록에 추가하지도 않았습니다. 설치 시간은 중간 규모 프로젝트의 경우 190 초 이상에서 깨끗한 캐시의 경우 약 25 초로 단축되었습니다. 내 우분투 머신은 그것보다 조금 더 빠르지 만 5-10 초 밖에 걸리지 않습니다.

하드웨어 구성 :
512GB SSD
12GB RAM
AMD FX-8350 8 코어 CPU @ 4.01ghz
Windows 10 64 비트, 빌드 14986.

내 시스템에서 몇 가지 간단한 테스트를 수행했습니다. 동일한 SSD에서 Linux Mint와 Windows 10 이중 부팅이 있습니다. 나는 삭제, 내 실 캐시를 청소 node_modules 달렸다 yarn 이에 VUE 프로젝트 .

리눅스 민트 : _12.22s_

Windows 10 (화이트 목록 없음) : _64.32s_

Windows 10 (화이트 목록 포함) : _42.58s_

다음은 내가 활성화 한 Windows Defender 제외 항목입니다.

화이트리스트가 상당한 영향을 미치는 것처럼 보였지만 여전히 Linux의 속도에 근접하지 않았습니다.

편집 : @bestander의 경우 정규화 된 데이터는 다음과 같습니다.

| OS | 계산 | 정규화 된 데이터 |
| --- | --- | --- |
| 리눅스 민트 | 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 초가 필요했습니다.

여기서 뱉어 내면 MSI 설치 프로그램의 Yarn.cmd를 사용하고 있으며 NPM에서 설치된 Yarn을 사용하는 것 같습니다. 아마 그들 사이에 불일치가 있는지 궁금합니다.

@nozzlegear 가능할 수도 있지만 인터넷 연결이 다르기 때문일 가능성이 적다고 생각합니다.

여기서 네트워크를 제거해야합니다.
현재 "Linux on Windows"기능이 활성화 된 최신 Windows 10 에서이 저장소를 테스트 할 수 있습니다.
CMD와 Bash를 통한 프라임 캐시 설치는 2 코어 i7 프로세서에서 약 27-29 초가 걸립니다.

@keawade , node_modules를 제거했지만 캐시를 제자리에두고 동일한 테스트를 실행할 수 있습니까?

아직 가지고있는 기기에 두 번째 OS를 설치할 수 없습니다.
가상 상자에서 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 작업에 타임 스탬프를 제공해야합니다.

캐시를 정리하지 않은 데이터

_ 참고 :이 데이터는 이중 부팅 시스템에 기록됩니다. 이 테스트에서 모든 하드웨어는 동일합니다 ._

| OS | 평균 시간 | 정규화 |
| ----------------------------- | ---------- | -------- ---- |
| 리눅스 민트 | 5.598 초 | 1.00000 |
| Windows 10 (화이트리스트 포함) | 12.119 초 | 2.16488 |
| Windows 10 (허용 목록 없음) | 31.578 초 | 5.64094 |

_ 평균 시간은 10 회 테스트 세트의 평균입니다 _

원시 Linux Mint 데이터

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

원시 Windows 10 데이터

화이트리스트 포함

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

화이트리스트없이

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

방법론

이 PowerShell 스크립트 를 사용하여 여기에 표시된 모든 데이터를 생성했습니다. 스크립트는 이 리포지토리를 복제하고 yarn 명령의 10 번 반복을 실행하여 각 반복 후에 node_modules 삭제합니다.

@bestander , 이전 게시물을 Windows 데이터로 업데이트했습니다.

더 많은 데이터에 감사드립니다.
두 OS의 타임 스탬프가있는 yarn.js로 --verbose 버전을 사용해 볼 수 있습니까?
시간이 어디에 사용되는지 우리에게 좋은 아이디어를 줄 것입니다.

휴, 그것은 많은 로깅입니다! 각 OS / 화이트리스트 조합에 대해 10 회 실행을 원합니까? 아니면 각 OS에 대해 1 회로 충분합니까?

@bestander 여기 있습니다! 각각 하나씩.

참고 : 단일 요점 컬렉션에 ~ 30MB의 원시 텍스트를 업로드하려고하면 nginx 405 오류가 발생합니다. 😆

~ 리눅스 민트 ~
~ 제외 및 깨끗한 Windows 10 ~
~ 제외가 있고 _clean_이없는 Windows 10 ~
~ 깨끗 하고 _exclusions_가없는 Windows 10 ~
~ _exclusions_ 및 _without_ clean이없는 Windows 10 ~

VerboseLogs.tar.gz

편집 : 요점을 제거하고 압축 파일을 업로드합니다.

단일 요점 컬렉션에 ~ 30MB의 원시 텍스트를 업로드하려고하면 nginx 405 오류가 발생합니다. 😆

파일 (bzip2 또는 7-Zip)을 압축하여 여기에 첨부 할 수 있습니다. 일반 텍스트는 매우 잘 압축됩니다. :)

@ Daniel15 좋은 지적입니다. 여기에 압축 파일이 있습니다. VerboseLogs.tar.gz

1 회 실행하면 괜찮을 것입니다. :)

LinuxMint.txt와 Windows10NoClean.txt를 비교했습니다.

리눅스 :

• 연결 단계는 1.156 초에 시작됩니다.
• 1.968에서 생성 된 node_modules 내의 모든 폴더
• 3.873 초에 복사 된 마지막 파일
• 빌드는 3 초 후에 완료됩니다.

윈도우

• 연결 단계는 2.779 초에 시작됩니다.
• 4.83에서 생성 된 node_modules 내의 모든 폴더
• 32.853에 복사 된 마지막 파일
• 빌드는 3 초 후에 완료됩니다.

분명히 자세한 로깅은 Windows (12-> 35 초)에서 실행 시간에 영향을 주지만 Linux에서는 그렇지 않습니다 (동일한 6 초).

인터넷에서 찾은 벤치 마크에서 Linux EXT3 FS는 일반적으로 많은 파일이 복사 될 때 NTFS를 능가합니다.
이것이 우리가 직면해야 할 한계인지 궁금합니다.

@keawade , Windows 및 Linux에서 npm @ 3 을 사용할 때 속도가 다른가요?

몇 가지 아이디어 :

• Windows는 동시 복사가 좋지 않을 수 있으며 파일을 4 스레드로 복사합니다. 단일 스레드일까요?
• Windows https://github.com/mikeobrien/node-robocopy 에서 robocopy 래퍼를 사용할 수
• readstream.pipe.writestream을 사용하여 파일을 복사합니다. Windows에서는 비효율적 일 수 있습니다.

실험하고 싶다면 https://github.com/yarnpkg/yarn/blob/master/src/util/fs.js#L322 에서 4 를 1 로 바꾸고 단일 스레드 복사가 Windows에서 더 빨라집니다.

스레드 테스트

@bestander의 요청에 따라, I는 두 갈래 yarnpkg/yarn 및 라인 (322) 변성 src/util/fs.js 교체하는, 4 로모그래퍼 1 . 그런 다음 yarn run build 를 사용하여 프로젝트를 빌드하고 빌드에서 컴파일 한 yarn.cmd 를 사용하여 해당 빌드로 10 개의 테스트 를

| | 평균 시간 | 정규화 |
| ---------------------------- | ---------- | --------- --- |
| Windows 10 (화이트리스트 포함) | 12.119 초 | 1.00000 |
| 단일 복사 스레드 | 16.927 초 | 1.39673 |
| 단일 복사 스레드 + 정리 | 42.268 초 | 3.48775 |

_ 평균 시간은 10 회 테스트 세트의 평균입니다 _

단일 스레드 만 사용하여 파일을 복사하면 설치 시간이 약간 느려집니다.

원시 데이터

Windows 10 (화이트리스트 포함)

이 데이터는 이전 테스트 에서 가져온 것입니다.

단일 복사 스레드

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

단일 복사 스레드 + 정리

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

감사합니다, @keawade.
NTFS가 Linux FS보다 많은 수의 파일을 복사 할 때 더 느릴 수 있다는 내 가정을 확인할 수 있습니까?

터미널 전체 설치된 node_modules를 통해 Linux Mint 및 Windows 10의 다른 위치로 복사하는 것을 측정하십시오.

/mt 옵션 (다중 스레드 복사본)과 함께 robocopy를 사용하여 복사본을 테스트해야합니다.

또한보고 된 버그를보고하고 싶습니다. yarn add 또는 yarn remove 약 30-40 분이 소요됩니다. 분명히 모든 종속성을 다시 복사하고 Windows를 사용하기 때문에 시간이 오래 걸립니다. 연결된 문제보기 :

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

@kumarharsh # 2458 설치를 마치는데 28

또한 캐시뿐만 아니라 프로젝트 폴더도 허용 목록에 추가하는 것을 잊지 마십시오.

복사 테스트

이 스크립트 를 사용하여 Linux Mint와 Windows 10에서 복사본을 10 번 반복 실행했습니다. 디렉터리에서 yarn 를 실행 한 후이 저장소를 복사

| OS | 평균 시간 | 정규화 |
| ------------ | ------------ | ------------ |
| 리눅스 민트 | 1527.4620 | 1.00000 |
| Windows 10 | 53676.3155 | 35.14085 |

그 시차는 미친 짓입니다. 이러한 복사는 _ 같은 SSD_의 한 위치에서 다른 위치로 파일을 복사하는 것입니다.

원시 데이터

리눅스 민트

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

윈도우 10

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

지금은 robocopy를 테스트 할 시간이 없지만 퇴근 후 오늘 저녁에 데이터를 얻을 수 있습니다.

Robocopy 테스트

이 스크립트 를 사용하여 Linux Mint와 Windows 10에서 복사본을 10 번 반복 실행했습니다. 디렉터리에서 yarn 를 실행 한 후이 저장소를 복사

| OS | 평균 시간 | 정규화 |
| ----------------------- | ------------ | ------------ |
| 리눅스 민트 | 1527.4620 | 1.00000 |
| Windows 10 | 53676.3155 | 35.14085 |
| Windows 10 (Robocopy) | 58089.7457 | 38.03024 |

Robocopy는 일반 복사보다 약간 더 나빴습니다.

원시 데이터

Linux Mint 및 Windows 10 값은 이전 테스트 에서 가져온 것입니다.

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

@keawade , 파일 인덱싱 및 Defender가 복사본을 방해하지 않는지 확인할 수 있습니까?
Afaik은 cp 명령에도 참여할 수 있습니다.

복사가 완료되면 작업 관리자에서 활성 상태를 확인하십시오.
테스트를 위해 해당 서비스를 끄고

인덱싱 및 방어자 테스트

다음 조건에서 테스트를 수행했습니다.

• 비활성화 된 Windows Defender 사용
• Windows 인덱싱 서비스 비활성화
• _both_ 비활성화 된 Windows Defender 및 Windows 인덱싱 서비스
• _both_ 비활성화 된 Windows Defender 및 Windows 인덱싱 서비스 _and_ Yarn 캐시 정리

Windows Defender를 비활성화하기 위해 Windows Defender 설정 패널 에서 Real-time protection 를 해제했습니다.

Windows 인덱싱을 비활성화하기 위해 서비스 제어판 에서 Windows 검색 서비스를 중지했습니다.

_ 참고 : Windows Defender가 활성화 된 경우 제외 항목이 나열되지 않았습니다 _

이 스크립트 를 사용하여 Linux Mint와 Windows 10 모두에서 10 번의 반복 복사본을 실행했습니다. 디렉터리에서 yarn 를 실행 한 후이 저장소를 복사

요약

Windows 인덱싱 (검색 서비스)이 복사 작업 및 Yarn에 영향을주는 것처럼 보이지만 Windows Defender에서 더 큰 영향을받습니다.

사자

| OS | 평균 시간 | 정규화 |
| -------------------------------------------- | ---- -------- | ------------ |
| 리눅스 민트 | 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의 성능에 대한 데이터를 사용할 수 있다고 생각했습니다.

이 스크립트 를 사용하여 Linux Mint와 Windows 10 모두에서 yarn 의 10 번 반복을 실행했습니다. 이 저장소를 복제하고 디렉터리에서 yarn 를 실행했습니다.

| OS | 평균 시간 | 정규화 |
| --------------------------------------------- | --- ------- | ------------ |
| 리눅스 민트 | 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 원사 Windows Defender 비활성화 됨

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

Windows 10 복사 Windows Defender 비활성화 됨

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

즉 모든 데이터를 공유하기위한 몇 가지 고체 연구, @keawade, 감사합니다.
데이터는 원시 파일 시스템 성능이 Windows에서 얀 설치의 병목임을 시사합니다.
제한을 우회하는 스마트 복사 명령이 없으면 Yarn이 여기서 아무것도 할 수 있는지 확실하지 않습니다.

@keawade 그 숫자를 컴파일하는 데 많은 어려움을 @bestander 그 이후로엄마 npm은 복사 (영구 스캔) 중에 이와 동일한 문제에 직면하지 않습니다. 실이 서명되지 않았을 수 있습니까? Windows 방어자가 npm과 같은 수준의 실을 신뢰하지 않을 수 있습니다. 그냥 생각 ...

@kumarharsh , npm과 yarn의 차이를 측정해야합니다.
npm이 더 적은 파일을 복사 할 수 있습니다 (Yarn의 호이 스팅은 가장 작은 node_modules 트리에 최적화되지 않았습니다).
그리고 설치 프로그램을 통해 자동으로 실을 화이트리스트에 올릴 수 있다면 좋을 것입니다.

원사가 서명되지 않았을까요? Windows 방어자가 npm과 같은 수준의 실을 신뢰하지 않을 수 있습니다.

스크립트에 서명 할 수 없다고 생각하므로 (Authenticode 서명을 지원하는 PowerShell 스크립트를 제외하고) Yarn과 npm이 그 점에서 다를 것이라고 생각하지 않습니다. Yarn의 설치 프로그램은 npm처럼 서명 된 Authenticode입니다.

그리고 설치 프로그램을 통해 자동으로 실을 화이트리스트에 올릴 수 있다면 좋을 것입니다.

바이러스 검색 허용 목록을 자동으로 만지면 바이러스 스캐너가 설치 프로그램을 맬웨어로 표시하는 것처럼 느껴집니다. 위험한 일인 것 같습니다. 하지만 검색 인덱서에서 디렉토리를 자동으로 블랙리스트에 올릴 수 있습니다.

@keawade /E /MT (다중 스레드 복사본) 옵션으로 robocopy를 테스트했습니다.

| 복사 방법 | 평균 시간 |
| ---------------------- | ---------- |
| 항목 복사 -Recurse | 20219 |
| Robocopy /E | 26652 |
| Robocopy /E /MT | 9043 |

원시 데이터 (Windows 10)

항목 복사 -Recurse

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

Robocopy /E

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

Robocopy /E /MT

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

스크립트에 서명 할 수 없다고 생각하므로 (Authenticode 서명을 지원하는 PowerShell 스크립트를 제외하고) Yarn과 npm이 그 점에서 다를 것이라고 생각하지 않습니다. Yarn의 설치 프로그램은 npm처럼 서명 된 Authenticode입니다.

합리적으로 들립니다.
이것을 다시 확인할 수 있습니까?
npm install 하면 Indexer와 Defender가 작업 관리자에 표시됩니까?

NPM Defender 및 인덱싱 테스트

Yarn 및 Windows 복사 방법에 대한 인덱싱 및 Defender 테스트와 동일한 조건 에서이 저장소 에서 npm install 를 실행하는 데 걸린 시간을 기록했습니다.

| OS | 평균 시간 | 정규화 |
| --------------------------------------------- | --- ------- | ------------ |
| 리눅스 민트 (사) | 5.5980 | 1.00000 |
| Linux Mint (NPM) | 28.9793 | 5.17672 |
| Windows 10 (방어자 없음) | 42.6296 | 7.61514 |
| Windows 10 (인덱싱 없음) | 53.8791 | 9.62470 |
| Windows 10 (방어자 없음, 인덱싱 없음) | 37.9727 | 6.78326 |
| Windows 10 (변경 없음) | 58.5047 | 10.45100 |

요약

NPM도 Windows Defender의 영향을받는 것 같습니다.

원시 데이터

NPM (Linux Mint)

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

NPM (Windows)

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

Windows Defender가 비활성화 된 NPM

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

Windows 인덱싱이 비활성화 된 NPM

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

Windows Defender 및 Windows 인덱싱이 비활성화 된 NPM

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

일반적으로 IO 작업 수를 줄이고 사람들에게 인덱싱 및 Defender에 대해 교육함으로써 디스크 IO에서 Windows가 느려지는 제한을 해결해야한다고 생각합니다.
사본을 robocopy로 교체하는 것도 좋은 생각 인 것 같습니다.

일반적으로 IO 작업 수 감소

이것은 일반적으로 좋은 아이디어이며 모든 곳에서 성능을 발휘하는 데 도움이 될 것입니다. 하드 드라이브가 느린 서버에 구축하는 사람들에게도 매우 유용 할 수 있습니다.

여기 에서 Windows

-업데이트
그러나 copyBulk에는 단일 robocopy 명령으로 변환되지 않을 수있는 제외와 같은 추가 로직이 있기 때문에 이것은 최적이 아닐 수 있습니다.

왜 이것이 나에게 (매번) 일어나는지 아는 사람이 있습니까?

게시물을 확장하려면 :
내 Windows 컴퓨터에서-모든 yarn add 또는 yarn rm 는 프로젝트의 모든 노드 모듈을 다시 복사하므로 package.json의 모든 변경 사항을 완료하는 데 시간이 엄청나게 오래 걸립니다. 160k 종속성에 대한 진행률 표시 줄은 매번 나타나며 유전에 좌초 된 거북이처럼 기어갑니다. yarn add -1000 초 전에 방금 수행 한 yarn rm paper 작업의 타이밍을 관찰하십시오!

그리고 add/rm 작업 중 하나를 취소하는 것은 불가능합니다. node_modules 폴더와 후속 yarn install / npm install 가 모든 종속성을 설치하지 않기 때문입니다. 결국 rm -r node_modules/ 하고 다시 시작합니다. 이 하나의 이유는 내가 원사 설치를 전혀 사용하지 못하게 할 정도로 고통 스럽습니다.

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 가 수정됩니다.
더 빨라야합니다

2017 년 2 월 15 일 수요일 20:04에 Hutson Betts [email protected] 은 다음과 같이 썼습니다.

@bestander https://github.com/bestander 님 의 소개
# 2620 https://github.com/yarnpkg/yarn/pull/2620 (어느
관리자 권한없이 Windows 7에서 잘 작동합니다.)
설치 시간 및 node_modules / 크기가 삭제되었습니다.

하드 링크없이 :

167.76s에서 완료되었습니다.

진짜 2m49.633s
사용자 0m0.229s
시스템 0m1.368s

du -sh node_modules /
216M node_modules /

하드 링크 사용 :

58.07 초에 완료되었습니다.

진짜 0m59.967s
사용자 0m0.183s
시스템 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 ... 새 패키지를 추가하려면이 시간을 기다려야했습니다.
수비수 끄기
인덱싱 비활성화

@Altiano가 언급 한대로 다음 단계를 따라 다른 AV를 실행하십시오.

AV에서 프로젝트 폴더 화이트리스트
AV에서 Yarn 캐시 디렉토리 ((% LocalAppData % Yarn))를 Whiteilst

이것에 업데이트됩니다

@kuncevic , 프로젝트의 새로 설치 시간은 얼마입니까?
파일에서 node_modules 폴더의 크기는 얼마입니까?
npm 설치와 비교하면 어떻습니까?

@bestander 이것은 나와 같은 문제입니다. yarn add 또는 yarn remove 는 @kittens 의 호이 스팅 수정 이후에도 약.

이런 일이 발생할 때마다 :

1. 먼저 Fetching packages 실행 (약 30 초 소요) :
   
2. 그런 다음 종속성 연결이 약 1 ~ 2 분 동안 일시 중지됩니다.
   
3. 그런 다음 다음 단계로 재개하고 63k 파일을 다시 설치합니다 (?).
   

내가 말했듯이 이것은 yarn add 또는 yarn remove 실행할 때마다 발생합니다. 내가 설치하는 종속성이 다른 종속성에 의존하는지 여부는 중요하지 않습니다. 새 종속성을 설치하거나 기존 종속성을 업그레이드하는 데 간단한 npm install 는이 시간의 일부가 걸립니다. @kittens 의 호이 스팅 수정으로 상황이 2 배 개선되었지만 여전히 시간이 너무 많이 걸립니다.

@bestander 재현 가능한 케이스를 원한다면이 저장소 https://github.com/kumarharsh/yarn-bug 를 복제하고 yarn install 실행 한 다음 yarn add react-helmet 하세요.

Yarn은 추가 / 제거를 실행할 때마다 결정 성을 유지하므로 종속성이 변경 될 때 node_modules의 루트에 종속성이 부여되었는지 확인해야합니다.
이것이 전체 연결 단계를 실행하는 이유입니다.

종속성 가져 오기-다운로드, 최적화 할 수 없습니다.
첫 번째 연결 단계 (1561 작업)-모든 종속성에 대한 모든 폴더를 만듭니다.
두 번째 연결 단계 (63K 작업)-파일을 캐시에서 node_modues로 복사합니다.

Yarn은 복사를 수행하기 전에 파일이 동일한 지 확인하여 파일 복사 작업을 최적화합니다.
이 영역을 더 잘 프로파일 링하고 불필요한 IO 수를 줄일 수 있는지 확인하고 싶을 수 있습니다.
아마도 Windows에서 복사가 더 빠를 것입니까?

npm은 어떻습니까? 새로 설치하는 속도는 얼마나됩니까?

npm ( npm install )을 새로 설치하려면 552301.1944ms 합니다.
추가 종속성 ( npm install weird )을 설치하려면 57023.7593ms 합니다. (대부분은 캔버스를 dep로 설치하려는 paperjs에서 낭비되지만 이번에는 npm과 yarn 모두에서 일반적입니다)

yarn ( yarn install )을 새로 설치하려면 612698.4915ms 합니다.
추가 종속성 ( yarn add weird )을 설치하려면 495633.0307ms 합니다.

npm version 3.10.9
yarn version 0.21.3

@bestander @kumarharsh Yarn은 노드 7.1 이상에 존재 하지 않는 libuv / nodejs 버그 (얀 코드의 잠재적 수정 사항은 # 2958 참조)로 인해 Windows에서 파일 복사 작업을 최적화하지 않으므로 두 번째 명령을 얻을 수 있습니다 ( yarn add ) 노드를 업그레이드하면 훨씬 빨라집니다.

Windows 파일 복사 작업을 사용하는 것은 노드 API를 사용하여 파일을 복사하는 것보다 조금 더 빠르며 (잠재적 인 PR에 대해서는 # 2960 참조) yarn install 을 약간 최적화하지만 다음과 같이 egalize할지 모르겠습니다. 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 와 관련하여 할 수있는 좋은 일은 원사로 인한 양과 파일 시스템, 하드 드라이브 및 안티 바이러스로 인한 양을 측정하는 것입니다.
내가 한 것은 실 캐시 어딘가에 material2 의 전체 node_module (npm이 아닌 yarn에 의해 생성됨)를 복사하는 것이 었습니다.

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 대의 PC에 대한 결과입니다.

• 🏠 가정용 PC : Samsung 950 Pro NVMe, ESET Nod32
• 🏢 업무용 PC : 삼성 850 EVO SATA, 비활성화 할 수없는 TrendMicro OfficeScan
• 🍎 MacBook Pro : 2015 버전, macOS, 안티 바이러스 없음

|| yarn 🏠 | npm 🏠 | xcopy 🏠 | yarn 🏢 | npm 🏢 | xcopy 🏢 | yarn 🍎 | npm 🍎
|-|-|-|-|-|-|-|-|-
| AV 비활성화 | 34s | 90 년대 | 23s |-|-|-| 32s | 92 년대
| AV 캐시 및 코드 제외 | 38s | 104 초 | 29 초 |-|-|-|-|-
| Av 캐시 만 제외 | 43s |-| 31s |-|-|-|-|-
| 평균 전체 | 48 초 | 122 초 | 32 초 | 100 초 | 274 초 | 236 초 |-|-

AV가 활성화 될 때마다 yarn install 또는 xcopy 동안 CPU 차트에서 상위권을 차지했습니다 (가정용 PC에서는 최대 30 % CPU를 사용했지만 업무용 PC에서는 xcopy를 위해 하나의 코어를 채 웁니다. & 원사에 대한 모든 코어)
xcopy는 yarn보다 내 작업 PC에서 느립니다. yarn이 수행하는 동안 파일을 병렬로 복사하지 않기 때문에 의심됩니다 (IO 바운드 작업에는 중요하지 않지만 AV는 CPU 바운드 작업으로 만들고 xcopy는 작성되지 않았습니다. 너무 어리석은 싸움 😄)

결론적으로

• yarn 는 npm 보다 빠르며 AV make file copy CPU 바운드 일 때 xcopy 보다 빠를 수도 있습니다.
• 좋은 SSD의 Windows는 정확히 동일한 패키지가 설치되지 않고 모든 설치 후 스크립트가 동일한 작업을 수행하지 않기 때문에 비교하기 어렵더라도 MacBook Pro 2015 (이미 좋은 SSD가 있음)보다
• 일부 변경은 원사에서 수행 할 수 있지만 (파일을 심볼릭 링크합니까?) 본질적으로 많은 작은 파일을 처리하는 것이 느립니다.
• Windows AV에서는 속도가 느려질 수 있습니다. 소스 및 대상 폴더 모두에서 활성화하면 30 %를 추가합니다. 😞
• 기업 AV는 가정용 AV 느릴 수 있으며 복사 작업이 고통 스러울만큼 성능을 ​​떨어 뜨릴 수 있습니다 (자연스러운 IO 바인딩 작업을 CPU에 바인딩 할 때) 😡

npm, yarn 캐시 폴더 및 node.exe를 방어자의 제외 목록에 추가하는 것으로 충분할 것입니다. 물론이 모든 것이 인덱싱 된 폴더에있을 수는 없습니다. 이제 yarn add / rm 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 Defender를 조정 했습니까?

   • 솔루션이 Windows Defender를 조정했다면 어딘가에서 수행 할 작업에 대한 완전한 설명이 있습니까?

2. 내 문제가 실제로이 스레드와 관련이 있습니까? 아니면 새 스레드를 만들어야합니까?

새로운 문제를 제기 해주셔서 감사합니다.

이제 거의 한 시간이 지났고이 명령이 프로세스를 완료하기를 기다리고 있습니다. @Altiano가 언급 한 위의 사항을

이것에 대한 대안이 있습니까? npm i -g . 사용할 수 있습니까? 같은 방식으로 작동합니까 아니면이 코드가 원사 workspace 사용하기 때문에 약간 변경해야합니다.

그래서 마지막으로 2-3시간 위해 고군분투 후, 나는 사용했다 npm i -g . 대신 yarn global add file:. . npm은 매력처럼 작동했습니다.