<p>25 공연이 있습니다</p>

퇴보해서 미안하지만

죄송합니다. 코드베이스를 공유할 수 없습니다.

우리가 아무것도 할 수 없다는 것을 의미합니다. 이것은 내가 24에서 25로 가는 성능의 10-40% _improvement_에서 들었던 다른 모든 곳에서 성능 퇴행에 대해 처음 들은 것입니다. 어떤 종류의 재생산을 제공해야 합니다. 그렇지 않으면 이 문제를 종료해야 합니다. 있는 그대로는 전혀 실행이 불가능하기 때문입니다.

이 문제가 해결된 것을 보고 싶다면 복제 케이스를 만드는 데 시간을 할애하거나 다른 사람이 해주기를 바랍니다.

좋습니다. 가장 느린 테스트 10개를 가져올 수 있는지 확인한 다음 24 대 25로 테스트를 실행해 보겠습니다. 그동안 CI에서 테스트를 실행하기 전에 캐시를 지우는 것과 관련하여 무엇을 권장합니까? 해? 하지마?

구성, 특히 transforms 및 설정 파일도 관련이 있을 수 있습니다.

CI에서 테스트를 실행하기 전에 캐시를 지우는 것과 관련하여 권장하는 사항은 무엇입니까?

나는 개인적으로 거짓 부정 또는 긍정을 제공하는 데 부실한 것이 없는지 확인하는 것이 좋은 생각이라고 생각합니다. 캐시를 지우지 _하지_ 않는 것이 테스트 런타임에 큰 차이를 줍니까?

캐시를 지운 후 실행하면 상당히 느려지는 것 같습니다. 팁을 주셔서 감사합니다. 나는 그것을 조사하고 재현을 시도할 수 있는지 확인할 것입니다.

FWIW, 나는 또한 v25가 v24와 동등하거나 약간 느리다는 것을 알았습니다. 거의 10-40% 개선을 본 적이 없습니다.

여기에 언급된 대로 jest 24에 비해 상당한 속도 향상을 보았습니다. https://github.com/facebook/jest/issues/7811#issuecomment -577057189

위의 내용은 osx에서 테스트되었습니다.

그러나 정확히 동일한 설정이 CentOS를 실행하는 CI에서 훨씬 더 느리게 실행됩니다.

Linux 관련 문제? 캐시 파일을 작성할 때 I/O 관련 문제가 있습니까? 이것을 배제하기 위해 캐시 생성을 완전히 끌 수 있습니까?

나는 우리의 경우에 범인을 찾았다고 생각합니다. 그것은 --collectCoverage 플래그입니다. Jest 24와 25 모두에 대해 제거되면 테스트가 25 미만에서 약 2배 빠르게 실행됩니다. 활성화되면 25 미만의 테스트는 24 미만의 동일한 테스트보다 거의 4배 느립니다.

이것은 OSX와 CentOS에서 모두 재현할 수 있으므로 이전 의견과 달리 Linux 관련 문제는 나타나지 않습니다.

흥미로운! 우리는 이스탄불을 v3로 업데이트했습니다. 아마도 거기에 무언가가 퇴보했을 것입니다. v8 코드 적용 범위에 대한 지원을 추가했으므로 그렇게 할 때 리팩토링을 엉망으로 만들 수도 있습니다.

네! 제가 본 것과도 일맥상통합니다. 우리는 2배 느린 CI에서 적용 범위를 실행하고 있습니다. 그리고 cov 없이 로컬에서 실행하면 매우 빠릅니다. @SimenB 이전 이스탄불을 사용하기 위한 구성 옵션이 있습니까? :)

@csvan 이 어쨌든 빌드하기 전에 삭제했기 때문에 실제로 범인이라면 CI에서 캐시 생성을 끄는 것이 좋을 것이라고 말한 것을 반영합니다.

나는 이것을 재현할 수 없다 - 내가 테스트한 repos는 v24와 v25 사이에 --coverage 거의 동일한 성능을 가지고 있다. 누군가 jest 24와 jest 25가 있는 저장소를 함께 만들 수 있습니까? 둘 사이를 전환하면 차이가 나타납니까?

커버리지가 비활성화된 상태로 CI 빌드를 실행했는데 @csvan 이 뭔가를 하고 있다고 생각합니다. 테스트는 적용 범위가 꺼진 상태에서 4:00에 실행되고 적용 범위가 켜진 상태에서 11분에 실행됩니다. 이번 주말에 어느 시점에서 재현을 만들 수 있는지 확인하려고 노력할 것입니다.

빌드 에이전트의 exinfo:

00:03:31.992   System:
00:03:31.992     OS: Linux 3.10 CentOS Linux 7 (Core)
00:03:31.992     CPU: (8) x64 Intel Core Processor (Skylake, IBRS)
00:03:31.992   Binaries:
00:03:31.992     Node: 10.16.0 - ~/workspace/grocery-electrode/tools/nix_64/nodejs-10.16.0/bin/node
00:03:31.992     npm: 6.9.0 - ~/workspace/grocery-electrode/tools/nix_64/npm-6.9.0/node_modules/.bin/npm
00:03:31.993   npmPackages:
00:03:31.993     jest: 25.1.0 => 25.1.0 

비슷한 문제가 발생했습니다. Jest 25를 업그레이드하면 적용 범위를 사용할 때 테스트 속도가 느려졌습니다(Jest 24의 166 대 Jest 25의 381). Jest 25에서 검사를 실행하는 동안 다음과 같은 많은 오류가 표시됩니다.

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0x10003d041 node::Abort() [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 2: 0x10003d24b node::OnFatalError(char const*, char const*) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 3: 0x1001b8e25 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 4: 0x100586d82 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 5: 0x100589855 v8::internal::Heap::CheckIneffectiveMarkCompact(unsigned long, double) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 6: 0x1005856ff v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 7: 0x1005838d4 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 8: 0x10059016c v8::internal::Heap::AllocateRawWithLigthRetry(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 9: 0x1005901ef v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
10: 0x10055fb34 v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationSpace) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
11: 0x1007e7e14 v8::internal::Runtime_AllocateInNewSpace(int, v8::internal::Object**, v8::internal::Isolate*) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
12: 0xb9c575dbe3d 
13: 0xb9c57ab091a 
14: 0xb9c579e7d65 
15: 0xb9c579ebaf3 

<--- Last few GCs --->

[733:0x102804000]    84639 ms: Mark-sweep 1335.2 (1449.6) -> 1325.4 (1452.1) MB, 1443.2 / 0.0 ms  (average mu = 0.135, current mu = 0.076) allocation failure scavenge might not succeed
[733:0x102804000]    85872 ms: Mark-sweep 1338.3 (1452.1) -> 1327.8 (1455.1) MB, 1159.4 / 0.0 ms  (average mu = 0.101, current mu = 0.059) allocation failure scavenge might not succeed


<--- JS stacktrace --->

Jest 24로 다운그레이드하면 이러한 오류가 사라집니다.

또한 Jest 25는 해당 구성에서 명시적으로 비활성화한 파일에서 적용 범위를 수집하는 것처럼 보이기 때문에 collectCoverageFrom 다르게 처리합니다. glob 구문에 대한 지원이 변경되었습니까?

JS 추적이 전혀 없습니까? 그것이 어디에서 죽었는지 보는 것은 흥미로울 것입니다.

나는 또한 Jest 25가 해당 구성에서 명시적으로 비활성화한 파일에서 적용 범위를 수집하는 것처럼 보이기 때문에 collectCoverageFrom을 다르게 처리한다는 것을 알았습니다. glob 구문에 대한 지원이 변경되었습니까?

Micromatch 4로 업그레이드했는데 뭔가 변경되었을 수 있습니다. 그러나 의도적으로 변경한 것은 아닙니다. 재생산에 대해 별도의 문제를 제기할 수 있습니까?

JS 추적이 전혀 없습니까?

다음과 같이 인쇄되었습니다.

==== JS stack trace =========================================

    0: ExitFrame [pc: 0x521cca5be3d]
Security context: 0x0ebfa799e6e9 <JSObject>
    1: _clearMemoizedQueries [0xebf2a5aba99] [/Users/evhaus/Git/zenhub/client/node_modules/jest-environment-jsdom/node_modules/jsdom/lib/jsdom/living/nodes/Node-impl.js:~208] [pc=0x521cd0d9a4e](this=0x0ebf5bee2aa9 <EventTargetImpl map = 0xebf7963d039>)
    2: _clearMemoizedQueries [0xebf2a5aba99] [/Users/evhaus/Git/zenhub/client/node_modules/jest-environment-...

편집 : 사실, 적용 범위가 비활성화된 경우에도 힙 오류가 표시됩니다.

Micromatch 4로 업그레이드했는데 뭔가 변경되었을 수 있습니다. 그러나 의도적으로 변경한 것은 아닙니다. 재생산에 대해 별도의 문제를 제기할 수 있습니까?

할 것이다.

다시 끼어듭니다. 적용 범위는 확실히 느리고 가짜인 것 같습니다. 다음은 OSX의 타이밍입니다.

46.69
41.77
45.06

v24 coverage
78.60
75.79
80.38

v25
45.93
52.49
53.36

v25 circus
61.27
52.08

v25 coverage
310.98
227.15
153.81

CI(트라비스)의 타이밍.

v24 coverage -w 4
101.634s

v25 coverage -w 4
178.306s

@milesj v25 서커스가 무엇인가요?

더 빨라야 하지만 내가 본 것과는 전혀 다른 새로운 주자라고 농담을 던집니다. https://www.npmjs.com/package/jest-circus

@EvHaus JSDOM의 Traces는 흥미롭습니다(물론 완전히 우연의 일치일 수도 있음). jest-environment-jsdom@24 하고 사용해 볼 수 있습니까? 우리는 11에서 15로 업그레이드 했으므로 거기에 무언가가 변경되었을 수 있습니다. 롱샷처럼 보이지만 누가 알겠습니까?

@SimenB 내 package.json 에서 jest-environment-jsdom 를 <24.0.0 로 롤백하는 것은 확실히 영향을 미쳤습니다. heap out of memory 오류가 사라지고 Jest가 문제 없이 실행을 완료하는 것 같습니다.

흥미로운! 시간되시면 테스트 해보면 좋을듯

• https://www.npmjs.com/package/jest-environment-jsdom-twelve
• https://www.npmjs.com/package/jest-environment-jsdom-thirteen
• https://www.npmjs.com/package/jest-environment-jsdom-fourteen

또는 jsdom 하고 이등분합니다. 내일 할게, 하지만 난 아직 좋은 재생산을 가지고 있지 않아

다음 테스트의 경우 적용 범위가 활성화되어 있지 않습니다.

• [email protected] 와 함께
  
  
  
  • 테스트를 실행하기 위한 143초
  
  
  • 문제 없음
  
  
• [email protected] 와 함께
  
  
  
  • 테스트를 실행하기 위한 154초
  
  
  • 문제 없음
  
  
• [email protected] 와 함께
  
  
  
  • 테스트를 실행하기 위한 228초
  
  
  • 🚨많은 JavaScript heap out of memory 오류
  
  

스택 추적

다음은 jest-environment-jsdom-fourteen 실행의 스택 추적입니다.

==== JS stack trace =========================================

    0: ExitFrame [pc: 0x20deef6dbe3d]
Security context: 0x36ee8219e6e9 <JSObject>
    1: _modified [0x36ee35982ec1] [/Users/evhaus/Git/zenhub/client/node_modules/jest-environment-jsdom-fourteen/node_modules/jsdom/lib/jsdom/living/nodes/Node-impl.js:~189] [pc=0x20deefba6433](this=0x36eef3246e99 <EventTargetImpl map = 0x36ee99264ee9>)
    2: _insert [0x36eeb41f1e41] [/Users/evhaus/Git/zenhub/client/node_modules/jest-environment-jsdom-fourte...

    0: ExitFrame [pc: 0x2aa5df5be3d]
Security context: 0x116a8d49e6e9 <JSObject>
    1: _clearMemoizedQueries [0x116a365133d1] [/Users/evhaus/Git/zenhub/client/node_modules/jest-environment-jsdom-fourteen/node_modules/jsdom/lib/jsdom/living/nodes/Node-impl.js:~208] [pc=0x2aa5dfe7dae](this=0x116a8f16cd11 <EventTargetImpl map = 0x116ae7cc9b61>)
    2: _clearMemoizedQueries [0x116a365133d1] [/Users/evhaus/Git/zenhub/client/node_modules/jest-...

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0x10003d041 node::Abort() [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 2: 0x10003d24b node::OnFatalError(char const*, char const*) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 3: 0x1001b8e25 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 4: 0x100586d82 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 5: 0x100589855 v8::internal::Heap::CheckIneffectiveMarkCompact(unsigned long, double) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 6: 0x1005856ff v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 7: 0x1005838d4 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 8: 0x10059016c v8::internal::Heap::AllocateRawWithLigthRetry(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 9: 0x1005901ef v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
10: 0x10055fb34 v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationSpace) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
11: 0x1007e7e14 v8::internal::Runtime_AllocateInNewSpace(int, v8::internal::Object**, v8::internal::Isolate*) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
12: 0x20deef6dbe3d 
13: 0x20deefba6433 

    0: ExitFrame [pc: 0xb8909f5be3d]
Security context: 0x09e628d9e6e9 <JSObject>
    1: childrenIterator [0x9e612e1d581] [/Users/evhaus/Git/zenhub/client/node_modules/symbol-tree/lib/SymbolTree.js:~367] [pc=0xb890a41010e](this=0x09e612e3eb01 <SymbolTree map = 0x9e6a7f56c09>,parent=0x09e685ca27d1 <EventTargetImpl map = 0x9e6061f36f1>,options=0x09e67b6026f1 <undefined>)
    2: arguments adaptor frame: 1->2
    3: _detach [0x9e65c4ae341] [/U...

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0x10003d041 node::Abort() [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 2: 0x10003d24b node::OnFatalError(char const*, char const*) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 3: 0x1001b8e25 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 4: 0x100586d82 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 5: 0x100589855 v8::internal::Heap::CheckIneffectiveMarkCompact(unsigned long, double) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 6: 0x1005856ff v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 7: 0x1005838d4 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 8: 0x10059016c v8::internal::Heap::AllocateRawWithLigthRetry(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 9: 0x1005901ef v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
10: 0x10055fb34 v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationSpace) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
11: 0x1007e7e14 v8::internal::Runtime_AllocateInNewSpace(int, v8::internal::Object**, v8::internal::Isolate*) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
12: 0x2aa5df5be3d 

    0: ExitFrame [pc: 0x180d6e95be3d]
Security context: 0x02052079e6e9 <JSObject>
    1: _modified [0x205b86c1861] [/Users/evhaus/Git/zenhub/client/node_modules/jest-environment-jsdom-fourteen/node_modules/jsdom/lib/jsdom/living/nodes/Node-impl.js:~189] [pc=0x180d6ede24fa](this=0x0205c8284411 <EventTargetImpl map = 0x205c1ea9769>)
    2: _attrModified [0x205b86ba771] [/Users/evhaus/Git/zenhub/client/node_modules/jest-environment-jsdom-fou...

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0x10003d041 node::Abort() [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 2: 0x10003d24b node::OnFatalError(char const*, char const*) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 3: 0x1001b8e25 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 4: 0x100586d82 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 5: 0x100589855 v8::internal::Heap::CheckIneffectiveMarkCompact(unsigned long, double) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 6: 0x1005856ff v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 7: 0x1005838d4 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 8: 0x10059016c v8::internal::Heap::AllocateRawWithLigthRetry(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 9: 0x1005901ef v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
10: 0x10055fb34 v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationSpace) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
11: 0x1007e7e14 v8::internal::Runtime_AllocateInNewSpace(int, v8::internal::Object**, v8::internal::Isolate*) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
12: 0xb8909f5be3d 

도움이 되었기를 바랍니다

이것이 도움이 될지 모르겠지만 우리 조직은 Jest 24에서 Jest 25(18분에서 28분)로 엄청난 속도 저하가 있었는데, 이는 커버리지 수집을 끈 후(10분까지) 사라졌습니다.

@rosasynstylae , 당신의 코드에 많은 스냅샷 테스트가 있습니까?

@benmonro 그렇습니다.

우리도 마찬가지! @SimenB 저장소의 많은 스냅샷이 이 문제를 일으킬 수 있다고 생각하십니까?

스냅샷이 없는 성능 문제가 있습니다. 우리는 보험을 수집하고 있습니다. 24 -> 25에서 상당한 속도 저하. 2개의 다른 프로젝트. 다양하지만 감속은 중요하고 일관적입니다.

나는 변경 없이 테스트를 계속해서 실행할 수 있으며 테스트는 24번의 테스트보다 평균 10배 더 느립니다.

24로 다시 전환하고 달리기는 우리가 사용했던 속도로 돌아갑니다.

필요한 경우 더 많은 정보를 제공할 수 있습니다. 스냅샷 테스트가 없는 2개의 프로젝트를 언급하고 싶었습니다.

여기에 있는 모든 의견에서 확실히 커버리지가 문제인 것처럼 들리고 아마도 이스탄불의 회귀일 것입니다.

여기에 있는 모든 의견에서 확실히 커버리지가 문제인 것처럼 들리고 아마도 이스탄불의 회귀일 것입니다.

나는 이스탄불을 손가락으로 가리킬 정도로 빠르지 않을 것이다. 제 경우에는 적용 범위가 비활성화된 경우에도 Jest 25에서 상당한 성능 및 안정성 문제를 보고 있습니다. https://github.com/facebook/jest/issues/9457#issuecomment -579423330을 참조

두 가지 개별 문제가 있을 수 있습니다.

1) jest-environment-jsdom-fourteen 관련 문제 및
2) 이스탄불 커버리지 문제

micromatch 를 ^3.0.0 다운그레이드하고 --coverage 사용하여 엄청난 속도 향상을 보았고 Jest 24에서 보았던 성능으로 어느 정도 되돌아갔습니다. 아무도 재현할 수 있습니까?

업데이트: 그러나 이제 --coverage 없이 실행하는 것도 Jest 24 수준의 성능으로 돌아갑니다. 두 배는 느립니다 :-/

@EvHaus 확인

micromatch 를 ^3.0.0 다운그레이드하고 --coverage 사용하여 엄청난 속도 향상을 보았고 Jest 24에서 보았던 성능으로 어느 정도 되돌아갔습니다. 아무도 재현할 수 있습니까?

업데이트: 그러나 이제 --coverage 없이 실행하는 것도 Jest 24 수준의 성능으로 돌아갑니다. 두 배는 느립니다 :-/

세상에... 내가 볼 수 있는 한 이스탄불에서 볼 수 있는 것은 마이크로매치에 의존하므로 그것이 적용 범위에 영향을 미치는 이유는 저를 넘어선 것입니다 🙁

전체 마이크로매치 성능이 다소 터무니없게 되었습니다. 커버리지 v3는 v4보다 빠르며 v4가 없으면 v3보다 빠릅니다. 😂

@SimenB 네, 확인을 위해 CI도 실행했습니다. 추가 외에는 변경하지 않음

  "resolutions": {
    "micromatch": "^3.0.0"
  }

package.json 은 --coverage 사용할 때 실행 시간을 6분 단축하여 Jest 24에서 본 것과 거의 동일하게 만들었습니다.

내가 볼 수있는 한 이스탄불에서는 마이크로 매치에 의존하지 않습니다.

이것과 관련될 수 있는 다른 스레드에서 이 댓글을 찾았습니다.

https://github.com/facebook/jest/issues/9464#issuecomment -579733243

이스탄불에서 micromatch 가져오는 것을 확인하지 않았습니다(바벨 플러그인에서 minimatch 사용).

제외가 제대로 작동하지 않는 문제일 수 있습니다. 무엇을 계측해야 하는지 확인하는 데 사용합니다. https://github.com/facebook/jest/blob/28f6da44cc58d41438bddfa9fcd741fd01b02ded/packages/jest-transform/src/shouldInstrument.ts. 당신은 아마도 거기에 몇 가지 기록을 충실하고 우리가 돌아 오면 볼 수 true 어디서나과 micromatch@4 우리가하지 않는 micromatch@3 ?

확실히 jsdom에 대한 문제와 적용 범위에 대한 문제의 두 가지 개별 문제처럼 느껴집니다.

micromatch@3 도 해결하면 CI에서 정상 속도로 돌아가는 것을 확인할 수 있습니다.

여기에 Jest + typescript + 반응 코드베이스가 있습니다. 이 문제를 보고 npm-force-resolutions를 사용하여 micromatch ^3.0.0을 강제 실행하면 엄청난 속도 저하가 해결되는 것 같았습니다.

구성에 커버리지 패턴에 대한 사용자 정의 테스트 파일 패턴이 있습니까?

@EvHaus jsdom 버전과의 큰 차이점을 보았을 때 Micromatch도 다운그레이드하여 차이점을 발견했다면 매우 관심이 있습니다.

이것이 당신이 의미하는 바라면 그렇습니다.

  collectCoverage: true,
  collectCoverageFrom: [
    'src/**/*.ts',
    'src/**/*.tsx',
    'src/**/*.js',
    'src/**/*.jsx',
    '!src/themes/**',
    '!src/**/Styled*.tsx',
    '!src/**/Styled*.ts',
    '!src/**/*Actions.ts',
    '!src/mainStore.ts',
    '!src/App.tsx',
    '!src/AppView.tsx',
    '!src/AppError.tsx',
    '!src/StyledAppComponents.tsx',
    '!src/index.tsx',
    'src/utility/redux/*.ts',
    '!src/testingUtils/*',
    '!src/**/index.ts',
    '!docs/**/**',
  ],

우리는 또한 그것을 가지고 있으며 우리의 길이/값이 매우 유사합니다.

@Ancient123 네

부정 패턴에 대한 Micromatch 회귀와 관련된 것 같습니다. 감사 해요!

최대한 빨리 조사하겠습니다.

전체 마이크로매치 성능이 약간 터무니없게 되어가고 있습니다.

성능저하 죄송합니다. 글로빙을 위한 정규 표현식을 생성하는 것은 보기보다 훨씬 어렵습니다. 특히 부정과 플랫폼 간을 처리해야 할 때. 지금 이것에 대해 조사하고 있습니다.

@jonschlinkert 비난하려는 의도는 전혀 없었습니다. Micromatch 및 관련 라이브러리에

네! @SimenB가 말한 것. ❤️

@EvHaus jsdom 버전과의 큰 차이점을 보았을 때 Micromatch도 다운그레이드하여 차이점을 발견했다면 매우 관심이 있습니다.

내 package.json 다음을 설정했습니다.

"resolutions": {
    "micromatch": "^3.0.0"
}

npm install 다시 실행한 다음 node_modules/jest/micromatch (버전 4에 있음)를 수동으로 삭제했습니다. 그런 다음 테스트를 다시 실행했습니다.

불행히도 "JavaScript heap out of memory" 오류가 여전히 많이 나타납니다.

다운그레이드를 제대로 하고 있습니까?

resolutions 는 yarn 하고 npm 는 아직 구현하지 않았습니다(v7의 로드맵에 있습니다: https://blog.npmjs.org/post/186983646370/npm- cli-로드맵-여름-2019)

@EvHaus npm v7이 나올 때까지 이 패키지와 함께 npm의 해상도를 사용할 수 있습니다: https://www.npmjs.com/package/npm-force-resolutions

지연 돼서 죄송합니다. npm-force-resolutions (올바른 일을 하고 있음)를 사용하여 micromatch 를 v3에 고정했습니다. 불행히도 내 힙 오류가 사라지지 않았습니다.

그래서 저를 위해 여기에 언급된 것처럼 여전히 [email protected] . https://github.com/facebook/jest/issues/9457#issuecomment -579423330

jsdom을 thirteen 로 해결하면 해결됩니다.

25에서 성능 저하를 경험한 사람이 jsdom@13 또는 micromatch@3을 사용하여 해결 되지 않는 문제가 있습니까? JSDOM의 메모리 누수가 수정되고 있으며(https://github.com/jsdom/jsdom/pull/2840 및 이에 연결된 다양한 문제/PR) micromatch의 회귀가 보고되어 작업 중입니다. https:// github.com/micromatch/micromatch/issues/179.

JSDOM 고정 버전이 출시되었습니다. jest-environment-jsdom-sixteen 를 설치하여 사용할 수 있습니다. @EvHaus 문제가 해결되는지 확인할 수 있습니까?

@SimenB 내 문제는 아마도 관련이 없지만 기본값을 사용하는 것과 비교하여 jest-environment-jsdom-sixteen 시도했고 반복 실행을 통해 동일한 테스트 제품군의 런타임이 20초 증가하는 것을 보았습니다.

v15(기본적으로 jest와 함께 제공됨)를 사용하고 다른 변경 사항은 없습니까? 16.1.0으로도 테스트할 수 있습니까(메모리 누수가 발생하므로 테스트가 더 어려울 수 있음). JSDOM이 사용자 정의 요소 지원과 함께 방금 착륙했습니다. 거기에 약간의 회귀가 _가능성_있습니까? 확실하지 않다

JSDOM 고정 버전이 출시되었으며 jest-environment-jsdom-sixteen을 설치하여 사용할 수 있습니다. @EvHaus 문제가 해결되는지 확인할 수 있습니까?

불행히도 jest-environment-jsdom-sixteen 여전히 힙 오류가 발생합니다. 나를 위한 JSDom의 마지막 안정적인 작업 버전은 jest-environment-jsdom-thirteen 입니다.

JSDOM 고정 버전이 출시되었습니다. jest-environment-jsdom-sixteen 를 설치하여 사용할 수 있습니다. @EvHaus 문제가 해결되는지 확인할 수 있습니까?

환경은 코드베이스와 함께 작동하지만 런타임에서 여전히 거의 100% 회귀를 보고 있습니다. 일화적으로 jest-environment-jsdom-sixteen 는 25.1 대 24.9 사용할 때만 실행 시간 성능을 10% 향상시키는 것으로 보입니다.

안녕하세요 @SimenB 님

https://github.com/olebedev/jest-perf-issue 에서 재현 가능한 사례를 만들었습니다 @joscha

결과

벤치마크는 MBP 2019, 32Gb RAM, i9-8950HK CPU @ 2.90GHz 에서 실행되었습니다.

| 농담 버전 | 지점 | 시간 |
|:-----------------|:------:|----------:|
| 24.9.0 | master | 348.077s |
| 25.1.0 | jest25 | 591.33s |

우리의 경우 jest v25.1이 v24.9에 비해 ~50% 느렸지만 이제 최신 jest v25.2.0은 v25.1에 비해 20% 더 느립니다 🙈

@olebedev 와, 고통스럽네요 😬

나는 당신과 비슷한 수치를 얻고 있습니다. 실제 프로젝트를 기반으로 하는 경우 v8 적용 범위를 사용하는 것이 좋습니다. 귀하의 재생산에서 내 컴퓨터의 런타임은 600초에서 35초로 걸립니다. 큰 차이가 나는 이유는 아마도 v8 적용 범위에서 적용되지 않은 파일을 계측하려고 하지 않기 때문일 것입니다(v8에서 작동하는 모든 바이트가 적용되지 않는다고 말합니다).

https://jestjs.io/docs/en/configuration#coverageprovider -string

왜 그렇게 느린지 잘 모르겠습니다... 시간을 들여 조사해 보겠습니다(곧은 아니지만). 적어도 v24보다 v25에서 느려서는 안 됩니다.

v8 적용 범위를 함께 사용할 수 있다는 문서를 올바르게 이해하고 있습니까?
...-sixteen 환경에서?

건배,
제이

2020년 4월 8일 수요일, 22:33 Simen Bekkhus, [email protected] 작성:

@olebedev https://github.com/olebedev 와, 고통스럽네요 😬

나는 당신과 비슷한 수치를 얻고 있습니다. 실제 프로젝트를 기반으로 하는 경우
v8 적용 범위를 사용하는 것이 좋습니다. 내 컴퓨터에서 런타임이 600초에서 35초로 걸립니다.
당신의 재생산에서 기계. 큰 차이의 이유는 아마도
v8 적용 범위에서 적용되지 않은 파일을 계측하려고 하지 않습니다.

https://jestjs.io/docs/en/configuration#coverageprovider -string

왜 이렇게 느린지 잘 모르겠습니다... 시간을 내서 살펴보겠습니다.
적어도 v24보다 v25에서 느려서는 안 됩니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/facebook/jest/issues/9457#issuecomment-610931770 또는
구독 취소
https://github.com/notifications/unsubscribe-auth/AABN5BW6R45SS5Z5GXGFGF3RLRVJLANCNFSM4KK67LOA
.

예, jest-environment-jsdom-sixteen 또는 번들 jest-environment-node 입니다. 또한 노드 8이 아닌 노드 10+에서만 지원됩니다.

(나는 이것을 노드 환경에서만 테스트했지만 jsdom 환경에서 작동하지 않으면 버그입니다. 별도의 문제를 열어주세요 🙂)

커버리지 제공자로서의 jest-environment-jsdom-sixteen + v8은 jest 25.3.0, 노드 12.16에서 약 20% 더 나쁩니다. 또한 테스트 성능이 jest 24에서 25로 약 80% 악화된 이유를 디버그하려고 합니다.

@joual 마이크로

여기에서 비슷한 경험을 하면 v25에서 테스트 시간(커버리지 없음)이 35-40초에서 80-90초로 두 배, 때로는 그 이상으로 늘어납니다. v3에서 마이크로매치를 잠그려고 했지만 측정할 수 있는 차이가 없었습니다. Fwiw, 약 3,000개의 테스트가 있으며 그 중 58개가 스냅샷 테스트입니다.
jsdom을 다운그레이드하려고 시도했지만 이것은 우리가 사용하고 있는 최근 기능으로 인해 많은 테스트 중단을 야기하는 것 같습니다. 어떻게든 이 문제를 해결하고 다시 보고할 수 있는지 확인하겠습니다.

@SimenB 더 예쁜 프로젝트의 커버리지 모으는 작업도 너무 느립니다, 확인 https://github.com/prettier/prettier/runs/579497097 Node.js 12 on ubuntu-latest 는 범위를 수집하지만 다른 작업은 수집하지 않습니다.

여기에서 비슷한 경험을 하면 v25에서 테스트 시간(커버리지 없음)이 35-40초에서 80-90초로 두 배, 때로는 그 이상으로 늘어납니다. v3에서 마이크로매치를 잠그려고 했지만 측정할 수 있는 차이가 없었습니다. Fwiw, 약 3,000개의 테스트가 있으며 그 중 58개가 스냅샷 테스트입니다.
jsdom을 다운그레이드하려고 시도했지만 이것은 우리가 사용하고 있는 최근 기능으로 인해 많은 테스트 중단을 야기하는 것 같습니다. 어떻게든 이 문제를 해결하고 다시 보고할 수 있는지 확인하겠습니다.

오늘 jest @24 (기본적으로 v11임)에서 다른 jsdom 버전으로 실험했습니다. v14까지는 모든 것이 잘 작동하는 것처럼 보이지만 v15부터 테스트 실행은 일관되게 50-60% 더 오래 걸립니다. v16에서도 같은 이야기. jsdom을 v14로 다운그레이드하여 jest @25 에서 비슷한 성능을 얻을 수 있는지 확인할 것입니다.

[email protected] 에는 일부 메모리 수정 사항이 있습니다. @EvHaus 를 사용해 볼 수 있습니까? Jest의 --detect-leaks 는 이전 버전에서 누출을 찾았지만 16.2.2에서는 발견하지 못했습니다.

또한 심볼릭 링크가 많은 경우(Windows에서는 매우 느림) 몇 가지 다른 개선 사항을 적용했습니다. 따라서 사람들이 [email protected] 을 사용해 볼 수 있다면 정말

@SimenB 그것을 테스트하는 가장 쉬운 방법은 무엇입니까? [email protected] devDependency로 직접 추가하면 Jest는 이를 무시하고 현재 15.2.1인 jest-environment-jsdom 와 함께 번들로 제공되는 것을 사용합니다.

내가 원하는 jsdom 버전을 사용하고 있는지 확인하기 위해 npm 를 어떻게 속일 수 있습니까?

jest-environment-jsdom-sixteen을 설치하고 https://jestjs.io/docs/en/configuration#testenvironment -string 사용

Alpha가 게시되었으므로 jest@next 시도할 수 있습니다. 기본적으로 jsdom 16과 함께 제공됩니다.

@SimenB 죄송합니다. [email protected] 및 [email protected] 운이 좋지 않습니다. 여전히 다음과 같은 오류가 많이 발생합니다.

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

그리고 결국 주자는 죽습니다.

내 세부 정보:

> npx envinfo --preset jest

  System:
    OS: macOS 10.15.4
    CPU: (8) x64 Intel(R) Core(TM) i5-8279U CPU @ 2.40GHz
  Binaries:
    Node: 10.17.0 - ~/.nvm/versions/node/v10.17.0/bin/node
    Yarn: 1.22.4 - /usr/local/bin/yarn
    npm: 6.14.4 - ~/.nvm/versions/node/v10.17.0/bin/npm
  npmPackages:
    jest: ^26.0.0-alpha.0 => 26.0.0-alpha.0 

다음은 그 중 일부에서 반환된 전체 스택입니다.

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0x10003d041 node::Abort() [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 2: 0x10003d24b node::OnFatalError(char const*, char const*) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 3: 0x1001b8e25 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 4: 0x100586d82 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 5: 0x100589855 v8::internal::Heap::CheckIneffectiveMarkCompact(unsigned long, double) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 6: 0x1005856ff v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 7: 0x1005838d4 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 8: 0x10059016c v8::internal::Heap::AllocateRawWithLigthRetry(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 9: 0x1005901ef v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
10: 0x10055fb34 v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationSpace) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
11: 0x1007e7e14 v8::internal::Runtime_AllocateInNewSpace(int, v8::internal::Object**, v8::internal::Isolate*) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
12: 0x3f82f50dbe3d 
13: 0x3f82f5c630de 
14: 0x3f82f5c94431 
15: 0x3f82f5c7d3be 
16: 0x3f82f5c4e98b 
17: 0x3f82f5c3c38e 

<--- Last few GCs --->

[50818:0x102804000]   189738 ms: Mark-sweep 1288.8 (1450.6) -> 1280.2 (1454.1) MB, 890.1 / 0.1 ms  (average mu = 0.181, current mu = 0.061) allocation failure scavenge might not succeed
[50818:0x102804000]   190673 ms: Mark-sweep 1292.8 (1454.1) -> 1282.9 (1457.6) MB, 856.2 / 0.2 ms  (average mu = 0.136, current mu = 0.084) allocation failure scavenge might not succeed


<--- JS stacktrace --->

==== JS stack trace =========================================

    0: ExitFrame [pc: 0x3f82f50dbe3d]
Security context: 0x274d67c9e6e9 <JSObject>
    1: createImpl [0x274d6d9ba1b9] [/Users/evhaus/Git/zenhub/client/node_modules/jsdom/lib/jsdom/living/generated/HTMLInputElement.js:~47] [pc=0x3f82f5c630de](this=0x274d51911261 <Object map = 0x274dd51fe489>,globalObject=0x274d89d38609 <Window map = 0x274d2fe6c211>,constructorArgs=0x274d832134b1 <JSArray[0]>,privateData=0x274d832134d1 <Object map = 0x274d69...

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0x10003d041 node::Abort() [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 2: 0x10003d24b node::OnFatalError(char const*, char const*) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 3: 0x1001b8e25 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 4: 0x100586d82 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 5: 0x100589855 v8::internal::Heap::CheckIneffectiveMarkCompact(unsigned long, double) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 6: 0x1005856ff v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 7: 0x1005838d4 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 8: 0x10059016c v8::internal::Heap::AllocateRawWithLigthRetry(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 9: 0x1005901ef v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
10: 0x10055fb34 v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationSpace) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
11: 0x1007e7e14 v8::internal::Runtime_AllocateInNewSpace(int, v8::internal::Object**, v8::internal::Isolate*) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
12: 0x2cea552dbe3d 
13: 0x2cea55937c04 
14: 0x2cea5592618b 

<--- Last few GCs --->

[51263:0x102804000]    34292 ms: Mark-sweep 1332.4 (1452.5) -> 1320.5 (1453.5) MB, 902.6 / 0.0 ms  (average mu = 0.149, current mu = 0.104) allocation failure scavenge might not succeed
[51263:0x102804000]    35480 ms: Mark-sweep 1332.6 (1453.5) -> 1323.6 (1457.5) MB, 1049.3 / 0.0 ms  (average mu = 0.131, current mu = 0.116) allocation failure scavenge might not succeed


<--- JS stacktrace --->

==== JS stack trace =========================================

    0: ExitFrame [pc: 0x2cea552dbe3d]
Security context: 0x1a4cb371e6e9 <JSObject>
    1: next [0x1a4ca627dcd1] [/Users/evhaus/Git/zenhub/client/node_modules/symbol-tree/lib/TreeIterator.js:~16] [pc=0x2cea55937c04](this=0x1a4c807c75b1 <TreeIterator map = 0x1a4c38b8a9c9>)
    2: shadowIncludingInclusiveDescendantsIterator(aka shadowIncludingInclusiveDescendantsIterator) [0x1a4ca627a641] [/Users/evhaus/Git/zenhub/client/node_modules/jsdom/li...

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0x10003d041 node::Abort() [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 2: 0x10003d24b node::OnFatalError(char const*, char const*) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 3: 0x1001b8e25 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 4: 0x100586d82 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 5: 0x100589855 v8::internal::Heap::CheckIneffectiveMarkCompact(unsigned long, double) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 6: 0x1005856ff v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 7: 0x1005838d4 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 8: 0x10059016c v8::internal::Heap::AllocateRawWithLigthRetry(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 9: 0x1005901ef v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
10: 0x10055fb34 v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationSpace) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
11: 0x1007e7e14 v8::internal::Runtime_AllocateInNewSpace(int, v8::internal::Object**, v8::internal::Isolate*) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
12: 0x3e0d8aedbe3d 
13: 0x3e0d8b35eedc 

<--- Last few GCs --->

[51519:0x102804000]    28074 ms: Mark-sweep 1324.5 (1445.0) -> 1315.7 (1449.0) MB, 760.4 / 0.0 ms  (average mu = 0.182, current mu = 0.080) allocation failure scavenge might not succeed
[51519:0x102804000]    28906 ms: Mark-sweep 1328.5 (1449.0) -> 1317.7 (1452.0) MB, 770.4 / 0.0 ms  (average mu = 0.129, current mu = 0.074) allocation failure scavenge might not succeed


<--- JS stacktrace --->

==== JS stack trace =========================================

    0: ExitFrame [pc: 0x3e0d8aedbe3d]
Security context: 0x3611d141e6e9 <JSObject>
    1: queueMutationRecord(aka queueMutationRecord) [0x361185f32321] [/Users/evhaus/Git/zenhub/client/node_modules/jsdom/lib/jsdom/living/helpers/mutation-observers.js:~33] [pc=0x3e0d8b35eedc](this=0x361116e826f1 <undefined>,type=0x3611aa0a3681 <String[9]: childList>,target=0x36110b275a91 <EventTargetImpl map = 0x3611a254a2f1>,name=0x361116e822b1 <null>,name...

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0x10003d041 node::Abort() [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 2: 0x10003d24b node::OnFatalError(char const*, char const*) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 3: 0x1001b8e25 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 4: 0x100586d82 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 5: 0x100589855 v8::internal::Heap::CheckIneffectiveMarkCompact(unsigned long, double) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 6: 0x1005856ff v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 7: 0x1005838d4 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 8: 0x10059016c v8::internal::Heap::AllocateRawWithLigthRetry(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 9: 0x1005901ef v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
10: 0x10055fb34 v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationSpace) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
11: 0x1007e7e14 v8::internal::Runtime_AllocateInNewSpace(int, v8::internal::Object**, v8::internal::Isolate*) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
12: 0x8d8aedbe3d 
<--- Last few GCs --->

[51526:0x102804000]    33125 ms: Mark-sweep 1318.6 (1425.0) -> 1317.7 (1424.0) MB, 874.8 / 0.0 ms  (average mu = 0.126, current mu = 0.038) allocation failure scavenge might not succeed
[51526:0x102804000]    33136 ms: Scavenge 1318.5 (1424.0) -> 1318.0 (1424.5) MB, 3.8 / 0.0 ms  (average mu = 0.126, current mu = 0.038) allocation failure 
[51526:0x102804000]    33148 ms: Scavenge 1318.7 (1424.5) -> 1318.2 (1425.0) MB, 4.2 / 0.0 ms  (average mu = 0.126, current mu = 0.038) allocation failure 


<--- JS stacktrace --->

==== JS stack trace =========================================

    0: ExitFrame [pc: 0x8d8aedbe3d]
    1: StubFrame [pc: 0x8d8ae8d40b]
    2: ConstructFrame [pc: 0x8d8ae8cfa3]
Security context: 0x3324ecd9e6e9 <JSObject>
    3: new NodeImpl(aka NodeImpl) [0x3324c2083e11] [/Users/evhaus/Git/zenhub/client/node_modules/jsdom/lib/jsdom/living/nodes/Node-impl.js:~125] [pc=0x8d8b357fd4](this=0x332437582801 <the_hole>,globalObject=0x3324b10f98e9 <Window map = 0x3324649cf0a1>,args=0x3324b1841471 <JSArray[0]>,...

너무 나쁩니다 😞 커버가 있는 건지 없는 건지

커버리지가 없는 상황이었습니다. 명확히 했어야 했다.

내가 상당히 오래된 버전의 Node(v10)를 실행하고 있는 것이 이에 대한 요인이 될 것이라고 생각하십니까?

새로운 버전을 사용해 볼 수 있습니다. 다른 것이 없다면 흥미로운 데이터 포인트가 될 것입니다. 다른 시도는 힙 덤프가 죽기 직전에 만드는 것입니다. 힙에 무엇이 있습니까?

아무도 micromatch@4 가 정규 표현식을 더 이상 캐시하지 않는다고 언급한 것이 흥미롭습니다( https://github.com/micromatch/micromatch/pull/151 및 https://github.com/facebook/jest/pull/10131 참조 누락 농담 쪽에서 캐싱.

나를 위해 micromatch@3으로 다운그레이드하고 jest-environment-jsdom-sixteen 업그레이드하면 50%의 시간이 절약됩니다.
그러나 jest 26 및 내장 jsdom을 사용하면 제 경우에는 --detectLeaks를 사용하여 jest를 실행할 때 여전히 누수 오류가 발생합니다. 신선한 repo를 시도했고 모두 잘 작동합니다.

https://github.com/facebook/jest/pull/10131 이 병합되었습니다!! <3

26.1.0에 릴리스되었으며 사람들에게 도움이 되는지 듣고 싶습니다.

@SimenB 출시

현재의:

os: osx
node: 12.6.1
jest: 24.9
-----------------
174 test suites
823 tests
322 snapshots
-----------------
done in 23.569s

24.9 이상의 모든 버전에서

os: osx
node: 12.6.1
jest: 26.1.0
-----------------
174 test suites
823 tests
322 snapshots
-----------------
done in 133.763s

새로운 캐시와 모든 노드 모듈의 완전한 재설치 후 모두. 손대지 않은 구성.
시계 모드에서 테스트를 실행하는 경우 실행할 테스트를 결정하는 데 내 컴퓨터에서 3분 이상 걸립니다. 재생산을 위해 문제를 분리할 수는 없지만 테스트할 사항에 대해 조언해 주시면 매우 관심이 있을 것입니다. 당신이 그것에 투자한 모든 작업에 감사드립니다!

@SimenB

prettier 프로젝트의 경우 적용 범위를 수집할 때 v24 보다 여전히 느립니다.

https://github.com/prettier/prettier/pull/8636

Bitbucket Pipeline에서 버전 25 및 26의 성능이 24보다 낮은 것을 확인할 수 있습니다. 또한 적용 범위가 활성화되면 속도가 느려지는 것으로 나타났습니다. 버전 25는 26에 비해 훨씬 더 나빠지고 메모리 소비로 인해 파이프라인이 충돌합니다.

@SimenB 24.9와 25.1 사이의 성능 회귀가 도입된 위치를 찾기 위해 git bisect 를 수행했습니다. 24.9에서 26.1까지 수정 없이 실행되기 때문에 더 예쁜 테스트를 사용했습니다.

비활성화된 캐시와 js 하위 집합의 세 번 실행(언젠가 안전을 위해)의 누적 런타임을 비교했습니다. 더 특별히 내가 사용하는 명령은 노드 10.19에서 ( yarn run jest --no-cache tests/js/ )이었습니다. 노드 10이 24.9의 권장 버전이었기 때문입니다.

결과:

24.9.0-dev 3cdbd556948b4974b2cc23178977eb159d343df8 151.84s <- Good
25.1.0-dev 5dcc48075f22d581864f381f20bc8b257d2a73cd 223.29s <- Bad
24.9.0-dev bf6109591365a2b71c7b642fa33ed06d3db6cb26 122.58s
24.9.0-dev 77c3ceedfd61ddc841e11fec7b76e540924d3e60 120.42s
24.9.0-dev 30e08e9ae7d7d78f40df757c2ec4b49357285eda 221.28s
24.9.0-dev ad5377333daf6716af3465bba39f86b7db485e2b 222.33s
24.9.0-dev 8ddadfca76eb3fb979df81033d3d0ff564c415d6 120.32s
24.9.0-dev 966f22f2a08d9ac9300b6964ab91c4e75dba4761 120.46s
24.9.0-dev b9084101189639524863e15ef7557ea6bc6704b9 119.87s
24.9.0-dev 1d8245d77d47b4198d51e55da87893d7dfe1a759 129.93s

ad5377333daf6716af3465bba39f86b7db485e2b is the first bad commit
commit ad5377333daf6716af3465bba39f86b7db485e2b
Author: Simen Bekkhus <[email protected]>
Date:   Mon Dec 2 23:20:16 2019 +0100

    feat: add support for `compileFunction` allowing us to avoid the module wrapper (#9252)

compileFunction 가 정의되지 않은 경우 대체가 있으므로 ad5377333daf6716af3465bba39f86b7db485e2b에서 compileFunction 분기를 제거하여 성능을 복원했습니다.

26.1을 보면 코드가 약간 이동했지만 compileFunction 및 대체가 여전히 있습니다. 그래서:

26.1.0-dev 817d8b6aca845dd4fcfd7f8316293e69f3a116c5 242.99s <- with compileFunction
26.1.0-dev 817d8b6aca845dd4fcfd7f8316293e69f3a116c5 151.61s <- without compileFunction

즉, compileFunction 분기( patch )를 제거하면 26.1이 24.9의 런타임으로 돌아갑니다. 나는 그것이 해결책이 아니라고 확신하지만 적어도 우리는 함께 일해야 합니다.

또 다른 데이터 포인트로서, 우리의 jest 제품군은 현재 업데이트 MR 에서는 약 3497초가 소요되어 약 27% 증가합니다.

모든 훌륭한 작업에 감사드립니다. 농담 팀입니다. @wurstbonbon 의 탐정 기술이 이러한 회귀 문제를 해결하는 데 도움이 되기를 바랍니다!

@wurstbonbon 시간을 compileFunction 이 더 느리다는 것은 매우 흥미로운 일입니다... 즉, 패치를 적용하는 대신 사용자 지정 테스트 환경을 사용할 수 있다는 의미입니다.

const NodeEnv = require('jest-environment-node');

class MyNodeEnv extends NodeEnv {}

delete MyNodeEnv.prototype.compileFunction;

module.exports = MyNodeEnv;

(jsdom 환경에서도 동일). 확인 할수 있어요?

병목 현상이 이상하게 들립니다. Node 자체가 18개월 전에 이를 사용하도록 전환했습니다: https://github.com/nodejs/node/pull/21573. 그래서 우리 측에서 뭔가 이상한 일을 하고 있는 것 같습니다. 링크된 https://github.com/nodejs/node/issues/26229 는 매우 흥미롭습니다. 어쩌면 우리 측에서 더 많은 캐싱을 수행해야 할까요?

@SimenB 방금 사용자 지정 환경과 비슷한 것을 시도했는데 조금 더 나은 것처럼 보입니다(그러나 여전히 jest 24보다 느림).

내가해야 할 일을했을 MyNodeEnv.prototype.getVmContext = null; I 26 농담으로 테스트하고 있습니다 때문에,하지만, 그것은 그것 같이에 대한 검사 보이는 if (typeof this._environment.getVmContext === 'function') { 해주기를 . 그러나 이것이 다른 문제를 일으킬 수 있는지 확실하지 않습니다.

다음은 몇 번의 실행 후에 보고 있는 결과입니다.

Jest 26 w/testEnvironment: "노드" => ~280초
Jest 26 w/커스텀 테스트 환경 => ~210s
농담 24 => ~160초

다른 정보나 다른 일을 도와드릴 수 있는지 알려주세요!

예상대로 사용자 정의 환경은 더 예쁜 것에 대해 동일한 속도 향상을 가져옵니다.

나는 또한 차이가 ~270s 대 ~200s인 우리의 코드베이스에서 시도해 보았으므로 40% 감소가 아니라 약 25%만 감소했습니다. 불행히도 우리는 새로운 현대 타이머 조롱에 의존하기 때문에 jest 24로 테스트를 실행할 수 없습니다.

위의 예에서 delete 를 놓쳤습니다. 죄송합니다.

컴파일된 함수를 수동으로 캐시하는 것으로 충분한지 궁금합니다. 이 패치를 적용해 볼 수 있습니까? (트랜스파일된 JS와 TS 소스 모두 여기에 포함됨)

diff --git i/packages/jest-runtime/build/index.js w/packages/jest-runtime/build/index.js
index 1d094a6dc0..f6d059caa3 100644
--- i/packages/jest-runtime/build/index.js
+++ w/packages/jest-runtime/build/index.js
@@ -267,6 +267,7 @@ const getModuleNameMapper = config => {
 const unmockRegExpCache = new WeakMap();
 const EVAL_RESULT_VARIABLE = 'Object.<anonymous>';
 const runtimeSupportsVmModules = typeof _vm().SyntheticModule === 'function';
+const compiledFunctionCache = new Map();
 /* eslint-disable-next-line no-redeclare */

 class Runtime {
@@ -1169,23 +1170,30 @@ class Runtime {
       value: this._createRequireImplementation(localModule, options)
     });
     const transformedCode = this.transformFile(filename, options);
-    let compiledFunction = null; // Use this if available instead of deprecated `JestEnvironment.runScript`
+    let compiledFunction = undefined; // Use this if available instead of deprecated `JestEnvironment.runScript`

     if (typeof this._environment.getVmContext === 'function') {
       const vmContext = this._environment.getVmContext();

       if (vmContext) {
-        try {
-          compiledFunction = (0, _vm().compileFunction)(
-            transformedCode,
-            this.constructInjectedModuleParameters(),
-            {
-              filename,
-              parsingContext: vmContext
-            }
-          );
-        } catch (e) {
-          throw (0, _transform().handlePotentialSyntaxError)(e);
+        const params = this.constructInjectedModuleParameters();
+        const cacheKey = transformedCode + params;
+        compiledFunction = compiledFunctionCache.get(cacheKey);
+
+        if (!compiledFunction) {
+          try {
+            compiledFunction = (0, _vm().compileFunction)(
+              transformedCode,
+              params,
+              {
+                filename,
+                parsingContext: vmContext
+              }
+            );
+            compiledFunctionCache.set(cacheKey, compiledFunction);
+          } catch (e) {
+            throw (0, _transform().handlePotentialSyntaxError)(e);
+          }
         }
       }
     } else {
@@ -1194,13 +1202,13 @@ class Runtime {
       const runScript = this._environment.runScript(script);

       if (runScript === null) {
-        compiledFunction = null;
+        compiledFunction = undefined;
       } else {
         compiledFunction = runScript[EVAL_RESULT_VARIABLE];
       }
     }

-    if (compiledFunction === null) {
+    if (!compiledFunction) {
       this._logFormattedReferenceError(
         'You are trying to `import` a file after the Jest environment has been torn down.'
       );
diff --git i/packages/jest-runtime/src/index.ts w/packages/jest-runtime/src/index.ts
index 522adabd1e..8958a4cef8 100644
--- i/packages/jest-runtime/src/index.ts
+++ w/packages/jest-runtime/src/index.ts
@@ -137,6 +137,8 @@ type RunScriptEvalResult = {[EVAL_RESULT_VARIABLE]: ModuleWrapper};

 const runtimeSupportsVmModules = typeof SyntheticModule === 'function';

+const compiledFunctionCache = new Map<string, ModuleWrapper>();
+
 /* eslint-disable-next-line no-redeclare */
 class Runtime {
   private _cacheFS: StringMap;
@@ -1000,24 +1002,29 @@ class Runtime {

     const transformedCode = this.transformFile(filename, options);

-    let compiledFunction: ModuleWrapper | null = null;
+    let compiledFunction: ModuleWrapper | undefined = undefined;

     // Use this if available instead of deprecated `JestEnvironment.runScript`
     if (typeof this._environment.getVmContext === 'function') {
       const vmContext = this._environment.getVmContext();

       if (vmContext) {
-        try {
-          compiledFunction = compileFunction(
-            transformedCode,
-            this.constructInjectedModuleParameters(),
-            {
+        const params = this.constructInjectedModuleParameters();
+
+        const cacheKey = transformedCode + params;
+
+        compiledFunction = compiledFunctionCache.get(cacheKey);
+
+        if (!compiledFunction) {
+          try {
+            compiledFunction = compileFunction(transformedCode, params, {
               filename,
               parsingContext: vmContext,
-            },
-          ) as ModuleWrapper;
-        } catch (e) {
-          throw handlePotentialSyntaxError(e);
+            }) as ModuleWrapper;
+            compiledFunctionCache.set(cacheKey, compiledFunction);
+          } catch (e) {
+            throw handlePotentialSyntaxError(e);
+          }
         }
       }
     } else {
@@ -1028,13 +1035,13 @@ class Runtime {
       );

       if (runScript === null) {
-        compiledFunction = null;
+        compiledFunction = undefined;
       } else {
         compiledFunction = runScript[EVAL_RESULT_VARIABLE];
       }
     }

-    if (compiledFunction === null) {
+    if (!compiledFunction) {
       this._logFormattedReferenceError(
         'You are trying to `import` a file after the Jest environment has been torn down.',
       );

나는 이것이 트릭을 할 수 있다고 생각했다.

const params = this.constructInjectedModuleParameters();
const cacheKey = transformedCode + params;
const cachedData = compileFunctionCache.get(cacheKey);

try {
  compiledFunction = (0, _vm().compileFunction)(
    transformedCode,
    params,
    {
      filename,
      parsingContext: vmContext,
      cachedData,
      produceCachedData: !cachedData,
    },
  );

  if (compiledFunction.cachedDataProduced) {
    compileFunctionCache.set(cacheKey, compiledFunction.cachedData);
  } 
} catch (e) {
  throw (0, _transform().handlePotentialSyntaxError)(e);
}

성능이 약간 향상되지만 Script 는 여전히 훨씬 빠릅니다.

@SimenB에서 추천을 시도 : https://gitlab.com/gitlab-org/gitlab/-/merge_requests/33252/diffs?commit_id=6d633c88caf70f712fa0ccaac42d952976161ec6

성능이 약간 향상되었지만 jest 24.x보다 여전히 상당히 느립니다.

• Jest 24.x: jest 테스트의 총 런타임 2580초
• Jest 26.x: jest 테스트의 총 런타임 3166초

@leipert 혹시 jsdom 환경을 14로 다운그레이드해 보셨나요?

jest 구성의 yarn add test-environment-jsdom-fourteen --dev + "testEnvironment": "test-environment-jsdom-fourteen" . 이것은 여전히 ​​우리를 위한 대부분의 지속 시간 증가(40-50% 추가)에 대한 책임이 있는 것으로 보이지만 여러 회귀가 있는 것처럼 보이기 시작했습니다.

@pleunv jest 24.x 에서는 jest-environment-jsdom-sixteen jsdom 16을 사용하고 있으며 웹 구성 요소 테스트와 관련된 몇 가지 문제로 인해 업그레이드해야 했습니다. 그래서 우리가 하는 유일한 변경은: jest 24.x + jest-environment-jsdom-sixteen -> jest.26x + jest-environment-jsdom 이므로 jsdom 버전은 변경되지 않습니다.

@wurstbonbon이 발견한 문제에 대해 https://github.com/nodejs/node/issues/35375 업스트림을 열었습니다.

@SimenB 마이크로 매치 에 대한 실행 가능한 대안을 알고 있습니까? 해당 리포지토리는 현재 반년 이상 침묵하고 있으며 https://github.com/micromatch/micromatch/issues/179 와 같은 Jest에 영향을 미치는 주요 문제는 여전히 열려 있습니다.

실제로는 대부분의 라이브러리에서 사용하는 것입니다. 예를 들어 minimatch를 볼 수 있지만 실행 가능한지 의심 스럽습니다.

@SimenB 모든 대안보다 마이크로

내가 연 문제에 대한 피드백을 바탕으로 Node에서 문제를 수정하려면 약간의 작업이 필요할 것 같으므로 지금은 Script 사용으로 되돌려야 한다고 생각합니다.

@leipert @wurstbonbon 또는 다른 사람, node_modules/jest-runtime/build/index.js 에서 이 패치를 사용해 볼 수 있습니까?

diff --git i/packages/jest-runtime/build/index.js w/packages/jest-runtime/build/index.js
index 851d8e12cd..7235082546 100644
--- i/packages/jest-runtime/build/index.js
+++ w/packages/jest-runtime/build/index.js
@@ -1170,35 +1170,24 @@ class Runtime {
       value: this._createRequireImplementation(localModule, options)
     });
     const transformedCode = this.transformFile(filename, options);
-    let compiledFunction = null; // Use this if available instead of deprecated `JestEnvironment.runScript`
+    let compiledFunction = null;
+    const script = this.createScriptFromCode(transformedCode, filename);
+    let runScript = null; // Use this if available instead of deprecated `JestEnvironment.runScript`

     if (typeof this._environment.getVmContext === 'function') {
       const vmContext = this._environment.getVmContext();

       if (vmContext) {
-        try {
-          compiledFunction = (0, _vm().compileFunction)(
-            transformedCode,
-            this.constructInjectedModuleParameters(),
-            {
-              filename,
-              parsingContext: vmContext
-            }
-          );
-        } catch (e) {
-          throw (0, _transform().handlePotentialSyntaxError)(e);
-        }
+        runScript = script.runInContext(vmContext, {
+          filename
+        });
       }
     } else {
-      const script = this.createScriptFromCode(transformedCode, filename);
-
-      const runScript = this._environment.runScript(script);
+      runScript = this._environment.runScript(script);
+    }

-      if (runScript === null) {
-        compiledFunction = null;
-      } else {
-        compiledFunction = runScript[EVAL_RESULT_VARIABLE];
-      }
+    if (runScript !== null) {
+      compiledFunction = runScript[EVAL_RESULT_VARIABLE];
     }

     if (compiledFunction === null) {

테스트 스위트에서 Script 를 사용하도록 패치를 테스트했으며 다음은 제가 얻은 결과입니다.
시간은 min:sec

이름 | 스위트 1 | 스위트 2 | 스위트 3 | 스위트 4
-- | -- | -- | -- | --
농담 24 | 3시 25분 | 3시 30분 | 3시 29분 | 0:53
농담 26 패치 | 3시 32분 | 4시 36분 | 3:48 | 0:53
농담 26 패치되지 않은 | 5시 10분 | 6시 12분 | 5시 11분 | 1:07
26 패치 대 24 | 4% | 31% | 9% | 1%
26 패치되지 않은 대 24 | 52% | 76% | 49% | 27%
26 패치 대 패치되지 않은 | 46% | 35% | 36% | 25%

v26이 v24에서 여전히 개선되지 않는다는 점은 여전히 ​​흥미롭습니다...

@셀룰 감사합니다! 그것으로 충분합니다 - 시간이 나면 PR을 작성하겠습니다.

멋진 물건! 그러면 Micromatch 문제만 남고 repo가 ​​다시 활성 유지 관리를 받게 되기를 바랍니다.

BTW, JSDOM에도 성능 회귀가 있다고 가정합니다. 내가 큰 웹 프로젝트에서 그런 테스트를 한 것처럼. 위에서 언급한 패치가 적용되지 않습니다.
그리고 그것은 그렇게 보였다.

Jest 24  (testEnvironment: "jsdom") (no rewires latest CRA)
144.014s

Jest 24 (testEnvironment: "jest-environment-jsdom-sixteen") (rewire latest CRA that changes testEnvironment)
409.473s (also few failed tests)

Jest 26 (testEnvironment: "jsdom") (no rewires latest CRA) so old jsdom? Whatever is the default for Jest 26 I assume? (I used react-app-rewired to rewire jest config and pnpmfile.js to override what version of Jest was installed with `react-scripts` as it still ships Jest 24 (like resolutions in yarn))
310.275s

Jest 26 (testEnvironment: "jest-environment-jsdom-sixteen") (rewire latest CRA that changes testEnvironment + pnpmfile.js)
over 1200s+ (some tests failed plus test run just stuck forever)

확실히 이것은 내가 유지해야 하는 매우 모호하고 불안정한 성능 보고서이지만 모든 입력이 도움이 된다고 생각합니다. :)

https://github.com/facebook/jest/releases/tag/v26.5.0 에는 여기에 논의된 vm.Script 변경 사항이 있습니다.

(편집: 추가 실행 후 업데이트됨)

동일한 테스트 스위트에 대한 예비 결과:

농담 26.5
감기: 59.992
핫: 43.976

농담 26.4:
감기: 90.213
핫: 47.408

콜드 런에서 매우 중요한 속도 향상 <3

내 테스트 스위트의 결과는 다음과 같습니다.

농담 26.5
감기: 149초

농담 26.4
감기: 226초

좋은 소식입니다 🙂 마이크로매치 회귀로 돌아간 것 같습니다.

npm-force-resolutions 를 사용하여 micromatch 3를 강제 설치하는 경우 [email protected] 에서 작동하지 않을 수 있습니다.

// package.json
  ...
  "preinstall": "npx npm-force-resolutions",
  ..
  "resolutions": {
    "micromatch": "^3.0.0"
  }

테스트 실행 시 오류:

TypeError: _micromatch(...).default.scan is not a function
    at globs.map.glob (/home/travis/build/removed/node_modules/jest-util/build/globsToMatcher.js:65:47)
    at Array.map (<anonymous>)
    at globsToMatcher (/home/travis/build/removed/node_modules/jest-util/build/globsToMatcher.js:61:26)
    at new SearchSource (/home/travis/build/removed/node_modules/@jest/core/build/SearchSource.js:197:49)
    at contexts.map.context (/home/travis/build/removed/node_modules/@jest/core/build/runJest.js:265:16)
    at Array.map (<anonymous>)
    at runJest (/home/travis/build/removed/node_modules/@jest/core/build/runJest.js:264:34)
    at startRun (/home/travis/build/removed/node_modules/@jest/core/build/cli/index.js:479:35)
    at runWithoutWatch (/home/travis/build/removed/node_modules/@jest/core/build/cli/index.js:494:10)
    at _run10000 (/home/travis/build/removed/node_modules/@jest/core/build/cli/index.js:416:13)
npm ERR! Test failed.  See above for more details.

@SimenB 업데이트 정말 감사합니다. [email protected] 업데이트한 후 Travis에서 실행 시간의 20%를 절약합니다.

결과:

v26.5입니다

• 323.98초
• 321.24초

v24.9입니다

• 262.17초
• 275.96초

@SimenB 감사합니다! 이것은 놀랍다. ~2000개 제품군에서 ~22000개 테스트에 대한 결과:

• Jest 24.x: 2864초
• Jest 26.5.2: 2967초

이는 우리가 이전에 본 ~27% 감속과 비교하여 약 3% 느리므로 오차 범위에 있습니다. 감사합니다. 이제 병합만 하면 됩니다. https://gitlab.com/gitlab-org/gitlab/-/merge_requests/33252#note_425616404

Jest 26.5.2 및 Node 14(이전에는 Node 10에 있었음)로 업그레이드한 후 이전에 겪었던 모든 "메모리 부족" 문제 가 사라졌습니다. Jest와 Node로 인해 얼마나 많은 문제가 발생했는지 확실하지 않지만 다른 사람들이 비슷한 문제를 보고 있다면 둘 다로 업그레이드해 보십시오.

업데이트 : 신경 쓰지 마세요. OOM 오류가 다시 발생하기 시작했습니다. 내 랩톱이 처리할 수 있는 경계선에 있고 처음 몇 번 실행은 좋았지만 지금은 다시 죽어가고 있습니다. 여전히 24.xx를 고수해야 합니다. :(

누군가 관심이 있다면 JSDOM에 비해 성능이 매우 좋은 DOM을 만들었습니다. Jest를 지원합니다.

| 운영 | JSDOM | 행복한 DOM |
| ------------------------------------ | ------- | ---------- |
| 가져오기 / 필요 | 333ms | 45ms |
| HTML 구문 분석 | 256ms | 26ms |
| HTML 직렬화 | 65ms | 8ms |
| 사용자 정의 요소 렌더링 | 214ms | 19ms |
| querySelectorAll('태그 이름') | 4.9ms | 0.7ms |
| querySelectorAll('.class') | 6.4ms | 3.7ms |
| querySelectorAll('[속성]') | 4.0ms | 1.7ms |
| querySelectorAll('[클래스~="이름"]') | 5.5ms | 2.9ms |
| querySelectorAll(':n번째 자식(2n+1)') | 10.4ms | 3.8ms |

프로젝트 링크:
https://github.com/capricorn86/happy-dom/

@capricorn86 이쁘네요. 사양을 준수합니까?

@capricorn86 이쁘네요. 사양을 준수합니까?

@milesj 감사합니다!

구현된 기능은 사양에 따라 구현되었지만 아직 어떤 사양이 적용되는지에 대한 자세한 개요는 없습니다. 추가할 생각입니다. 그러나 모든 기능은 단위 테스트에 포함됩니다.

DOM의 초기 목표는 다른 프로젝트에 필요했기 때문에 웹 구성 요소를 좋은 성능으로 서버 측에서 렌더링할 수 있도록 하는 것이었습니다.

FWIW, 방금 Jest 24.9의 react-scripts@3 @react-scripts@4 에서 Jest 26.6의

우리의 서버 API 테스트 스위트는 이전에 약 180-190초 동안 실행되었습니다. Jest 26.6으로 전환한 후 지속적으로 약 220초가 소요되었습니다. minimatch 를 4.0.2 강제로 해결하려고도 했습니다. 테스트 러너를 jest-circus 전환하면 몇 초가 걸리는 것처럼 보이지만 전반적으로 26.6은 눈에 띄게 느려집니다.

react-scripts@4 는 기본적으로 fwiw로 jest-circus 를 사용합니다. 또한 micromatch 가 아니라 우리가 사용하는 minimatch 입니다. 그러나 #10131을 통해 micromatch 롤백을 중단한 것 같으므로 더 이상 회귀의 원인인지 테스트하기가 쉽지 않습니다.

@SimenB : atm에 이상한 마이그레이션 설정이 있습니다. CRA를 사용하여 빌드하도록 변환 한 레거시 MEAN/AngularJS 앱입니다. 테스트 구성은 기본 제공 CRA Jest 구성과 비교하여 모두 우리 자신의 것입니다. 우리는 CRA가 Jest와 함께 종속성으로 제공된다는 사실을 이용하고 있습니다.

나는 ATM 앞에 내 작업 상자가 없기 때문에 실제로 micromatch 의미했는지 또는 실제로 거기에 잘못된 패키지 이름에 집중했는지 기억할 수 없습니다. :) 살펴봐야 할 것입니다. 다음주에 다시.

방금 v26이 macOS의 기본 터미널보다 iTerm에서 _많이_ 느리게 실행된다는 사실을 알게 되었습니다. 6500개의 테스트 세트에서 일관되게 다음과 같은 결과를 얻습니다.

• v24, 터미널: ~90s
• v24, iTerm2: ~90년대
• v26, 터미널: ~110s
• v26, iTerm2: ~150초

이것은 속도 저하를 해결하기 위해 여러 가지를 시도한 몇 달 후 내 마음을 조금 날려 버렸다. Mac에서 성능 문제가 있는 다른 사람이 이것을 시도할 수 있는 기회가 있습니까? 참고로 이것은 v26의 jsdom@14 입니다.

@pleunv 나는 이것이 관련이 있을 수 있다고 생각합니다: https://github.com/facebook/jest/pull/9294. 하이퍼링크가 내 컴퓨터의 iTerm2를 느리게 만들어 고르지 못하게 만드는 것으로 나타났습니다. 그러나 전반적인 실행 속도를 조사하지 않았으며 문제가 있는 다른 사람을 찾지 못했습니다.

유레카. "iTerm"을 검색하면 이 PR이 나옵니다 . 나는 이전에 이러한 밑줄을 알아차렸고 그것이 하이퍼링크라는 것을 깨닫지 못했습니다. 그 PR을 본 후 iTerm에서 하이퍼링크를 비활성화하여 런타임을 130초로 낮췄습니다. PR에서 코드를 적용하고 하이퍼링크를 제거한 후 다시 120초로 돌아갑니다. 이성이 약간 회복되었습니다.

PR을 다시 시작할 수 있는 기회가 있습니까?

편집: @thymike 가 저를 이겼습니다 😄

@pleunv 이번 주에 시간을 내서 다시 가져오도록 노력하겠습니다. 실제 거래는 iTerm에 대해 이 문제를 수정하는 것이지만 Linux의 다른 터미널에는 하이퍼링크에 문제가 없습니다. iTerm 프로젝트에 문제를 제출하시겠습니까?

방금이 변경을 수행했으며 단일 테스트 파일에 대해 1을 제공했습니다. URL을 계속 클릭할 수 있으며 더 이상 밑줄이 표시되지 않습니다.

이것은 더 큰 실행에 대해 거대할 수 있습니다. ❤️

//편집하다
웃긴 것은 그것이 텀이든 터미널이든 이전에는 아무런 차이가 없었습니다. 변경 후 나를 위해 더 빠릅니다.

@pleunv 이번 주에 시간을 내서 다시 가져오도록 노력하겠습니다. 실제 거래는 iTerm에 대해 이 문제를 수정하는 것이지만 Linux의 다른 터미널에는 하이퍼링크에 문제가 없습니다. iTerm 프로젝트에 문제를 제출하시겠습니까?

여기 에서 문제를 만들었습니다(GitLab에 있음). 누군가 추가 세부 사항이나 재현 프로젝트가 있으면 자유롭게 추가하십시오.

그 사이에 좀 더 실험을 해보니 더 작은 테스트 하위 집합(20개 테스트 파일)에서만 실행할 때 하이퍼링크가 일반적으로 큰 차이를 만들지 않는다는 것을 알았습니다. 전체 세트(700개 파일)에서 실행할 때 그 영향은 매우 측정 가능합니다.

나는 또한 장기적으로 jest의 콘솔 출력이 정말 글리치/플래시가 되기 시작한다는 인상을 받았습니다. 예를 들어 하단의 진행 라인은 보이는 것보다 숨겨져 있습니다.