<p>es gibt eine 25 leistung</p>

Entschuldigung für den Rückschritt, aber

Entschuldigung, wir können unsere Codebasis nicht teilen

bedeutet, dass wir absolut nichts tun können. Dies ist das erste Mal, dass ich von Leistungsrückgängen gehört habe, überall habe ich von 10-40% _Verbesserung_ der Leistung von 24 auf 25 gehört. Sie müssen eine Art Reproduktion bereitstellen, sonst müssen wir dieses Problem schließen da es in seiner jetzigen Form überhaupt nicht umsetzbar ist.

Wenn Sie dies behoben sehen möchten, müssen Sie einige Zeit damit verbringen, einen Reproduktionskoffer zusammenzustellen, oder hoffen, dass jemand anderes dies tut.

ok, ich werde sehen, ob ich vielleicht unsere 10 langsamsten Tests durchführen kann, und dann versuchen, sie in 24 vs 25 auszuführen. Was empfehlen Sie in der Zwischenzeit in Bezug auf das Löschen des Caches, bevor Sie Tests in CI ausführen? Tu es? tu es nicht?

Ihre Konfiguration, insbesondere transforms und Setup-Dateien sind wahrscheinlich ebenfalls relevant

Was empfehlen Sie in Bezug auf das Löschen des Caches, bevor Sie Tests in CI ausführen?

Ich persönlich denke, es ist eine gute Idee, nur sicherzustellen, dass nichts abgestandenes herumliegt und falsch negative oder positive Ergebnisse liefert. Macht es einen großen Unterschied für die Laufzeit Ihrer Tests, den Cache _nicht_ zu leeren?

Es scheint etwas langsamer zu sein, wenn es nach dem Löschen des Cache ausgeführt wird. danke für die tipps ich werde mir das mal anschauen und mal schauen ob ich eine repro versuchen kann

FWIW, mir ist auch aufgefallen, dass v25 entweder etwas langsamer ist oder mit v24 gleichkommt. Habe noch keine annähernd 10-40% Verbesserung gesehen.

Ich habe eine deutliche Beschleunigung gegenüber Jest 24 festgestellt, wie hier angegeben: https://github.com/facebook/jest/issues/7811#issuecomment -577057189

Das obige wurde auf osx getestet.

Das exakt gleiche Setup läuft jedoch auf unserem CI, auf dem CentOS ausgeführt wird, viel, viel langsamer.

Linux-spezifisches Problem? E/A-bezogene Probleme beim Schreiben von Cache-Dateien? Ist es möglich, die Cache-Generierung ganz zu deaktivieren, um dies auszuschließen?

Ich glaube, ich habe den Schuldigen in unserem Fall gefunden, es ist das --collectCoverage Flag. Wenn es sowohl für Jest 24 als auch für 25 entfernt wird, laufen unsere Tests unter 25 ungefähr doppelt so schnell. Wenn es aktiviert ist, sind unsere Tests unter 25 fast viermal so langsam wie die gleichen unter 24.

Dies ist sowohl auf OSX als auch auf CentOS reproduzierbar, so dass das Problem entgegen meinem vorherigen Kommentar nicht Linux-spezifisch erscheint.

Interessant! Wir haben Istanbul auf v3 aktualisiert, vielleicht hat sich da etwas zurückgebildet. Wir haben Unterstützung für v8-Code-Coverage hinzugefügt, daher habe ich möglicherweise auch das Refactoring durcheinander gebracht

Ja! Das stimmt auch mit dem überein, was ich sehe. Wir arbeiten mit Abdeckung in CI, wo sie 2x langsamer ist. Und wenn ich lokal ohne covg laufe ist das ziemlich schnell. @SimenB gibt es eine Konfigurationsoption, um das ältere Istanbul zu verwenden? :)

Um das zu @csvan sagte, wäre es schön, die Cache-Generierung in CI zu Übeltäter ist, da wir es sowieso vor dem

Ich kann dies nicht reproduzieren - die von mir getesteten Repos haben ungefähr die gleiche Leistung mit --coverage zwischen v24 und v25. Könnte jemand ein Repository mit jest 24 und jest 25 zusammenstellen, bei dem das Umschalten zwischen ihnen einen Unterschied zeigt?

Ich habe gerade unseren CI-Build mit deaktivierter Abdeckung ausgeführt, ich denke, @csvan hat etwas vor. Die Tests laufen um 4:00 Uhr mit ausgeschalteter Abdeckung vs. 11 Minuten mit eingeschalteter Abdeckung. Ich werde versuchen zu sehen, ob ich dieses Wochenende irgendwann Repro erstellen kann.

unsere Exinfo vom Build-Agent:

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 

Wir sehen ein ähnliches Problem. Durch das Upgrade von Jest 25 wurden unsere Tests bei Verwendung der Abdeckung langsamer (166s mit Jest 24 vs. 381s mit Jest 25). Jest 25 zeigt viele dieser Fehler an, während die Prüfungen ausgeführt werden:

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

Ein Downgrade auf Jest 24 lässt diese Fehler verschwinden.

Mir ist auch aufgefallen, dass Jest 25 die collectCoverageFrom anders handhabt, da es anscheinend Abdeckung von Dateien sammelt, die wir in dieser Konfiguration explizit deaktiviert haben. Hat sich dort die Unterstützung für die Glob-Syntax geändert?

Irgendwelche JS-Spuren überhaupt? Wäre interessant zu sehen, wo es gestorben ist.

Mir ist auch aufgefallen, dass Jest 25 CollectCoverageFrom anders behandelt, da es anscheinend Coverage von Dateien sammelt, die wir in dieser Konfiguration explizit deaktiviert haben. Hat sich dort die Unterstützung für die Glob-Syntax geändert?

Wir haben auf Micromatch 4 aktualisiert, es könnte sich etwas geändert haben. Es werden jedoch absichtlich keine Änderungen daran vorgenommen. Könnten Sie mit einer Reproduktion ein separates Thema eröffnen?

Irgendwelche JS-Spuren überhaupt?

Dies wurde gedruckt:

==== 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-...

BEARBEITEN : Tatsächlich sehe ich Heap-Fehler, auch wenn die Abdeckung deaktiviert ist.

Wir haben auf Micromatch 4 aktualisiert, es könnte sich etwas geändert haben. Es werden jedoch absichtlich keine Änderungen daran vorgenommen. Könnten Sie mit einer Reproduktion ein separates Thema eröffnen?

Wird besorgt.

Wieder reinschnuppern. Die Abdeckung ist definitiv langsamer und scheint unecht zu sein. Hier sind die Zeiten für 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

Timings für CI (travis).

v24 coverage -w 4
101.634s

v25 coverage -w 4
178.306s

@milesj was ist v25 zirkus?

Es ist ein Scherz neuer Läufer, der schneller sein soll, aber das ist es nie, was ich gesehen habe. https://www.npmjs.com/package/jest-circus

@EvHaus Traces von JSDOM ist interessant (könnte natürlich auch völlig zufällig sein). Könnten Sie versuchen, jest-environment-jsdom@24 installieren und das zu verwenden? Wir haben von 11 auf 15 aktualisiert, also könnte sich da etwas geändert haben. Klingt wie ein Longshot, aber wer weiß

@SimenB Das jest-environment-jsdom auf <24.0.0 in meinem package.json definitiv eine Wirkung gezeigt. Die heap out of memory Fehler sind weg und Jest scheint seine Läufe ohne Probleme abzuschließen.

Interessant! Wenn du Zeit hast, wäre es schön, wenn du testen könntest

• 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

Oder einfach in jsdom verlinken und halbieren. Das mache ich morgen, aber eine wirklich gute Reproduktion habe ich noch nicht

Für die folgenden Tests habe ich keine Abdeckung aktiviert.

• Mit [email protected]
  
  
  
  • 143 Sekunden zum Ausführen von Tests
  
  
  • Keine Probleme
  
  
• Mit [email protected]
  
  
  
  • 154 Sekunden zum Ausführen von Tests
  
  
  • Keine Probleme
  
  
• Mit [email protected]
  
  
  
  • 228s zum Ausführen von Tests
  
  
  • 🚨Viele JavaScript heap out of memory Fehler
  
  

Stapelspuren

Dies sind einige der Stack-Traces aus dem jest-environment-jsdom-fourteen Lauf:

==== 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 

Hoffe das hilft

Ich weiß nicht, ob dies helfen wird, aber meine Organisation hatte eine massive Verlangsamung von Jest 24 auf Jest 25 (18 Minuten auf 28 Minuten), die nach dem Deaktivieren der Berichterstattung (auf 10 Minuten) verschwunden war.

@rosasynstylae aus Neugier, enthält Ihr Code viele Snapshot-Tests?

@benmonro Das tut es, ja.

Unsere auch! @SimenB denkst du, dass viele Snapshots in einem Repo dies verursachen könnten?

Wir haben die Leistungsprobleme ohne Snapshots. Wir sammeln jedoch Berichterstattung. Deutliche Verlangsamung von 24 -> 25. 2 verschiedene Projekte. Es variiert, aber die Verlangsamung ist signifikant und konsistent.

Ich kann die Tests ohne Änderungen immer wieder ausführen und die Tests sind im Durchschnitt 10 Mal langsamer als bei 24.

Ich wechsle zurück auf 24 und die Läufe sind wieder in der Geschwindigkeit, die wir gewohnt waren.

Bei Bedarf kann ich weitere Infos liefern. Ich wollte unbedingt unsere 2 Projekte ohne Snapshot-Tests erwähnen.

Von all den Kommentaren hier hört es sich definitiv so an, als ob die Berichterstattung das Problem ist und wahrscheinlich ein Rückschritt in Istanbul?

Von all den Kommentaren hier hört es sich definitiv so an, als ob die Berichterstattung das Problem ist und wahrscheinlich ein Rückschritt in Istanbul?

Ich würde nicht so schnell mit dem Finger auf Istanbul zeigen. In meinem Fall sehe ich selbst bei deaktivierter Abdeckung erhebliche Leistungs- und Stabilitätsprobleme in Jest 25. Siehe https://github.com/facebook/jest/issues/9457#issuecomment -579423330

Es ist möglich, dass es zwei verschiedene Probleme gibt:

1) Probleme mit jest-environment-jsdom-fourteen und
2) Probleme mit der Istanbul-Abdeckung

Ich habe micromatch auf ^3.0.0 herabgestuft und mit --coverage eine massive Beschleunigung festgestellt, mehr oder weniger zurück zu der Leistung, die wir unter Jest 24 gesehen haben. Kann das jemand reproduzieren?

UPDATE: Das Ausführen ohne --coverage ist jetzt jedoch auch wieder auf dem Leistungsniveau von Jest 24 - doppelt so langsam :-/

@EvHaus danke für die Überprüfung, sehr interessant! Das kann ich leider immer noch nicht reproduzieren. Eine Reproduktion wäre also immer noch toll, so kann ich versuchen, dies zu debuggen.

Ich habe micromatch auf ^3.0.0 herabgestuft und mit --coverage eine massive Beschleunigung festgestellt, mehr oder weniger zurück zu der Leistung, die wir unter Jest 24 gesehen haben. Kann das jemand reproduzieren?

UPDATE: Das Ausführen ohne --coverage ist jetzt jedoch auch wieder auf dem Leistungsniveau von Jest 24 - doppelt so langsam :-/

Was in aller Welt ... Soweit ich in Istanbul nichts sehen kann, hängt von Micromatch ab, also warum es sich auf die Abdeckung auswirken sollte, ist mir schleierhaft

Die ganze Sache mit der Micromatch-Performance wird ein bisschen absurd, mit Abdeckung ist v3 schneller als v4, ohne v4 ist es schneller als v3? 😅

@SimenB ja, habe es auch durch unser CI

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

to our package.json hat die Laufzeit bei Verwendung von --coverage um solide 6 Minuten verkürzt, was ungefähr wieder das ist, was wir unter Jest 24 gesehen haben.

Soweit ich sehen kann, hängt in Istanbul nichts von Micromatch ab

Habe diesen Kommentar in einem anderen Thread gefunden, der damit zusammenhängen könnte:

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

Gerade bestätigt, dass nichts in Istanbul micromatch einzieht (sie verwenden minimatch im Babel-Plugin).

Es könnte definitiv daran liegen, dass Ausschlüsse nicht richtig funktionieren. Wir verwenden es, um zu überprüfen, was wir instrumentieren sollen: https://github.com/facebook/jest/blob/28f6da44cc58d41438bddfa9fcd741fd01b02ded/packages/jest-transform/src/shouldInstrument.ts. Könnten Sie sich vielleicht dort einloggen und sehen, ob wir true irgendwo mit micromatch@4 , die wir für micromatch@3 ?

Es fühlt sich auf jeden Fall wie 2 separate Probleme an, eines über jsdom und eines über die Berichterstattung

Ich kann bestätigen, dass die Geschwindigkeit für uns in CI wieder normal ist, wenn wir auch micromatch@3 auflösen.

Scherz + Typoskript + reagieren Codebasis hier. Dieses Problem zu sehen und npm-force-resolutions zu verwenden, um Micromatch ^3.0.0 zu erzwingen, schien die verrückte Verlangsamung zu beheben.

Haben Sie benutzerdefinierte Testdateimuster oder Abdeckungsmuster in Ihrer Konfiguration?

@EvHaus Ich bin sehr daran interessiert, ob Sie auch einen Unterschied durch das Downgrade von Micromatch sehen, da Sie bei jsdom-Versionen einen großen Unterschied gesehen haben

Wenn Sie das meinen, dann ja.

  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/**/**',
  ],

das haben wir auch und unseres sieht in Länge/Werten ziemlich ähnlich aus

@Ancient123 ja, genau. Scheint im Zusammenhang mit der Micromatch-Regression für negierte Muster zu stehen. Danke!

Scheint im Zusammenhang mit der Micromatch-Regression für negierte Muster zu stehen. Danke!

Angemerkt, ich werde es so schnell wie möglich prüfen.

Die ganze Sache mit der Micromatch-Performance wird ein bisschen absurd

Entschuldigung für die Leistungseinbußen. Reguläre Ausdrücke für das Globbing zu generieren ist viel schwieriger, als es aussieht. Vor allem, wenn es mit Negation umgehen und plattformübergreifend sein muss. Ich schaue mir das jetzt an.

@jonschlinkert es war überhaupt nicht anklagend gemeint, die Arbeit, die du in Micromatch und verwandte Bibliotheken

ja! was @SimenB gesagt hat. nichts als ️

@EvHaus Ich bin sehr daran interessiert, ob Sie auch einen Unterschied durch das Downgrade von Micromatch sehen, da Sie bei jsdom-Versionen einen großen Unterschied gesehen haben

In meinem package.json setze ich:

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

npm install ausführen und dann node_modules/jest/micromatch manuell löschen (was in Version 4 war). Dann habe ich meine Tests erneut durchgeführt.

Leider sehe ich immer noch viele "JavaScript-Heap nicht genügend Speicher"-Fehler.

Mache ich das Downgrade richtig?

resolutions benötigt yarn , npm hat es noch nicht implementiert (es steht auf der Roadmap für v7: https://blog.npmjs.org/post/186983646370/npm- cli-roadmap-sommer-2019)

@EvHaus bis npm v7 herauskommt, können Sie Auflösungen in npm mit diesem Paket verwenden: https://www.npmjs.com/package/npm-force-resolutions

Entschuldigung für die Verspätung. Verwendet npm-force-resolutions (was das Richtige tut), um micromatch auf v3 zu sperren. Leider hat es meine Heap-Fehler nicht verschwinden lassen.

Also für mich ist es immer noch [email protected] schuld, wie hier erwähnt: https://github.com/facebook/jest/issues/9457#issuecomment -579423330

Das Auflösen von jsdom in thirteen behebt es.

Hat jemand, der in 25 eine Leistungseinbuße erlebt hat, Probleme, die nicht durch die Verwendung von jsdom@13 oder micromatch@3 behoben werden können https:// github.com/micromatch/micromatch/issues/179.

Eine korrigierte Version von JSDOM wurde veröffentlicht, Sie können sie verwenden, indem Sie jest-environment-jsdom-sixteen installieren. @EvHaus könnten Sie überprüfen, ob es Ihr Problem behebt?

@SimenB mein Problem hängt wahrscheinlich nicht zusammen, aber ich habe jest-environment-jsdom-sixteen Vergleich zur Verwendung der Standardeinstellung ausprobiert und bei wiederholten Durchläufen eine Erhöhung der Laufzeit um 20 Sekunden für dieselbe Testsuite festgestellt.

über die Verwendung von v15 (was standardmäßig mit jest geliefert wird) und keine anderen Änderungen? Könnten Sie auch mit 16.1.0 testen (obwohl dies zu Speicherverlusten führt, daher möglicherweise schwieriger zu testen). JSDOM ist gerade mit benutzerdefinierter Elementunterstützung gelandet, gibt es _möglicherweise_ eine Regression? Nicht sicher

Eine feste Version von JSDOM wurde veröffentlicht, Sie können sie verwenden, indem Sie jest-environment-jsdom-sixteen installieren. @EvHaus könnten Sie überprüfen, ob es Ihr Problem behebt?

Bekomme leider immer noch Heap-Fehler mit jest-environment-jsdom-sixteen . Die letzte stabil funktionierende Version von JSDom ist für mich jest-environment-jsdom-thirteen .

Eine korrigierte Version von JSDOM wurde veröffentlicht, Sie können sie verwenden, indem Sie jest-environment-jsdom-sixteen installieren. @EvHaus könnten Sie überprüfen, ob es Ihr Problem behebt?

Die Umgebung funktioniert mit unserer Codebasis, aber wir sehen immer noch eine fast 100%ige Regression in der Laufzeit. Anekdotisch scheint jest-environment-jsdom-sixteen die Laufzeitleistung nur um 10 % zu verbessern, wenn 25.1 Vergleich zu 24.9

Hallo @SimenB ,

Ich habe den reproduzierbaren Fall hier https://github.com/olebedev/jest-perf-issue erstellt. Bitte werfen Sie einen Blick darauf. Untenstehendes Ergebnis zum Vergleich. /cc @joscha

Ergebnisse

Benchmarks wurden auf MBP 2019, 32Gb RAM, i9-8950HK CPU @ 2.90GHz .

| Scherzversion | Zweig | Zeit |
|:--------------|:------:|----------:|
| 24.9.0 | master | 348.077s |
| 25.1.0 | jest25 | 591.33s |

In unserem Fall, wo jest v25.1 im Vergleich zu v24.9 ~50 % langsamer war, ist jetzt die neueste jest v25.2.0 im Vergleich zu v25.1 noch 20 % langsamer 🙈

@olebedev Woah, das tut weh 😬

Ich bekomme ähnliche Zahlen wie Sie. Wenn es auf einem echten Projekt basiert, empfehle ich die Verwendung von v8-Abdeckung. Es dauert die Laufzeit von 600s bis 35s auf meiner Maschine in Ihrer Reproduktion. Der Grund für den großen Unterschied ist wahrscheinlich, dass wir nicht versuchen, nicht abgedeckte Dateien mit v8-Abdeckung zu instrumentieren (wir sagen nur, dass jedes Byte aufgedeckt wird, was mit v8 funktioniert).

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

Ich bin mir nicht sicher, warum es so langsam ist ... Ich werde versuchen, etwas Zeit zu finden, um es zu untersuchen (wird jedoch nicht so schnell sein). Es sollte zumindest auf v25 nicht langsamer sein als auf v24

Verstehe ich die Dokumente richtig, dass wir die v8-Abdeckung gemeinsam nutzen können?
mit der ...-sixteen Umgebung?

Beifall,
J

Am Mi, 8. April 2020, 22:33 Uhr schrieb Simen Bekkhus, [email protected] :

@olebedev https://github.com/olebedev Woah, das tut weh 😬

Ich bekomme ähnliche Zahlen wie Sie. Wenn es auf einem echten Projekt basiert, dann
empfehlen die Verwendung von v8-Abdeckung. Es dauert die Laufzeit von 600s bis 35s auf meinem
Maschine in Ihrer Reproduktion. Der Grund für den großen Unterschied ist wahrscheinlich das
wir versuchen nicht, nicht abgedeckte Dateien mit v8-Abdeckung zu instrumentieren.

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

Ich bin mir nicht sicher, warum es so langsam ist ... Ich werde versuchen, etwas Zeit zu finden, um es zu untersuchen.
Es sollte zumindest auf v25 nicht langsamer sein als auf v24

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/facebook/jest/issues/9457#issuecomment-610931770 oder
Abmelden
https://github.com/notifications/unsubscribe-auth/AABN5BW6R45SS5Z5GXGFGF3RLRVJLANCNFSM4KK67LOA
.

Ja, entweder jest-environment-jsdom-sixteen oder das gebündelte jest-environment-node . Beachten Sie auch, dass es nur auf Knoten 10+ unterstützt wird, nicht auf Knoten 8.

(Ich habe das immer nur mit der Node env getestet, aber wenn es mit der jsdom env nicht funktioniert ist das ein Bug - bitte eröffne ein separates Problem 🙂)

jest-environment-jsdom-sixteen + v8 als Abdeckungsanbieter war für uns auf jest 25.3.0, Knoten 12.16 um etwa 20 % schlechter. Wir versuchen auch zu debuggen, warum sich unsere Testleistung von jest 24 auf 25 um etwa 80 % verschlechtert hat.

@joual hast du den Micromatch-Workaround ausprobiert (Downgrade auf 3.x)?

Mit einer ähnlichen Erfahrung hier verdoppeln sich die Testzeiten (_ohne_ Abdeckung) auf v25 von 35-40 Sekunden auf 80-90 und manchmal mehr. Versucht, Micromatch auf v3 zu sperren, kein messbarer Unterschied. Fwiw, wir haben ungefähr 3k Tests, von denen 58 Snapshot-Tests sind.
Es wurde versucht, jsdom herunterzustufen, aber dies scheint aufgrund der neuesten Funktionen, die wir verwendet haben, viele Testfehler zu verursachen. Werde mal sehen ob ich das irgendwie umgehen kann und melde mich dann wieder.

@SimenB Der Auftrag zum https://github.com/prettier/prettier/runs/579497097 Node.js 12 on ubuntu-latest sammelt Berichterstattung, andere Jobs nicht.

Mit einer ähnlichen Erfahrung hier verdoppeln sich die Testzeiten (_ohne_ Abdeckung) auf v25 von 35-40 Sekunden auf 80-90 und manchmal mehr. Versucht, Micromatch auf v3 zu sperren, kein messbarer Unterschied. Fwiw, wir haben ungefähr 3k Tests, von denen 58 Snapshot-Tests sind.
Es wurde versucht, jsdom herunterzustufen, aber dies scheint aufgrund der neuesten Funktionen, die wir verwendet haben, viele Testfehler zu verursachen. Werde mal sehen ob ich das irgendwie umgehen kann und melde mich dann wieder.

Habe heute mit verschiedenen jsdom-Versionen auf jest@24 (standardmäßig v11) experimentiert. Bis v14 scheint alles gut zu funktionieren, aber ab v15 dauern Testläufe durchweg 50-60% länger. Gleiche Geschichte in v16. Ich werde sehen, ob ich bei jest@25 eine ähnliche Leistung erzielen kann, indem ich jsdom auf v14 herunterstufen kann.

[email protected] hat einige Speicherkorrekturen, @EvHaus könntest du es ausprobieren? Jests eigenes --detect-leaks findet Lecks in früheren Versionen, aber nicht 16.2.2.

Ich habe auch einige andere Verbesserungen erzielt , wenn Sie viele Symlinks haben (was unter Windows sehr langsam ist). Wenn die Leute also könnten , wäre das schön 🙂

@SimenB Wie kann man das am einfachsten testen? Wenn ich [email protected] direkt als devDependency hinzufüge, ignoriert Jest dies und verwendet alles, was mit jest-environment-jsdom gebündelt ist, was heute 15.2.1 ist.

Wie kann ich npm austricksen, um sicherzustellen, dass die gewünschte jsdom-Version verwendet wird?

Installieren Sie jest-environment-jsdom-sixteen und verwenden Sie es https://jestjs.io/docs/en/configuration#testenvironment -string

Alpha veröffentlicht, damit Sie jest@next ausprobieren können - es kommt mit jsdom 16 out of the box

@SimenB Entschuldigung, nicht viel Glück mit [email protected] und seinen [email protected] . Immer noch viele dieser Fehler:

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

Und irgendwann stirbt der Läufer.

Meine Details:

> 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 

Hier sind einige der vollständigen Stapel, die von diesen zurückgegeben wurden:

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]>,...

Schade 😞 Ist das mit oder ohne Abdeckung?

Das war ohne Deckung. Hätte klären sollen.

Glaubst du, dass ich eine ziemlich alte Version von Node (v10) verwende, wäre ein Faktor dafür?

Sie können versuchen, neuere Versionen zu verwenden, ansonsten wäre dies ein interessanter Datenpunkt. Andere Dinge, die Sie versuchen sollten, ist zu versuchen, einen Heap-Dump zu erstellen, bevor er stirbt. Was ist auf dem Haufen?

Es ist interessant, dass niemand erwähnt hat, dass micromatch@4 keine Regexps mehr zwischenspeichert (siehe https://github.com/micromatch/micromatch/pull/151 und https://github.com/facebook/jest/pull/10131 führt fehlende ein Caching auf der Scherzseite.

Für mich hat ein Downgrade auf Micromatch@3 und ein Upgrade auf jest-environment-jsdom-sixteen 50% Zeit gespart.
Aber mit jest 26 und eingebautem jsdom erhalte ich immer noch einen Leckfehler, wenn ich in meinem Fall jest mit --detectLeaks ausführe. Habe frisches Repo probiert und alles funktioniert gut.

https://github.com/facebook/jest/pull/10131 wird zusammengeführt!! <3

Veröffentlicht in 26.1.0, sehr daran interessiert zu hören, ob es den Leuten hilft

@SimenB vielen Dank für die Veröffentlichung! Leider stehen wir auf unserer Seite immer noch vor einem großen Unterschied:

Strom:

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

auf jeder Version höher als 24.9

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

sowohl mit frischen Caches als auch nach einer kompletten Neuinstallation aller Node-Module. unberührte Konfigurationen.
Ausführen von Tests im Watch-Modus Es dauert mehr als 3 Minuten auf meinem Computer, um zu bestimmen, welche Tests ausgeführt werden sollen. Ich kann das Problem für eine Reproduktion nicht wirklich isolieren, aber wenn Sie mir ein paar Ratschläge geben, was ich testen soll, wäre ich sehr daran interessiert. danke für die ganze arbeit die du da reingesteckt hast!

@SimenB

Für prettier Projekte immer noch langsamer als v24 beim Sammeln von Berichterstattung.

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

Ich kann bestätigen, dass die Leistung der Versionen 25 und 26 in der Bitbucket Pipeline niedriger ist als die von 24. Mir ist auch aufgefallen, dass die Langsamkeit mit aktivierter Abdeckung zunimmt. Version 25 wird im Vergleich zu 26 noch schlimmer und die Pipeline stürzt aufgrund des Speicherverbrauchs ab.

@SimenB Ich habe git bisect , um herauszufinden, wo die Leistungsregression zwischen 24,9 und 25,1 eingeführt wurde. Ich habe die schöneren Tests verwendet, weil sie von 24.9 bis 26.1 ohne Änderungen laufen.

Ich habe die kumulierte Laufzeit von drei Durchläufen der js-Teilmenge (um etwas Zeit zu sparen) mit deaktiviertem Cache verglichen. Genauer gesagt war der Befehl, den ich verwende ( yarn run jest --no-cache tests/js/ ) mit Knoten 10.19. weil Knoten 10 die empfohlene Version für 24.9 war.

Ergebnisse:

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)

Da es einen Fallback gibt, wenn compileFunction nicht definiert ist, habe ich den compileFunction Zweig aus ad5377333daf6716af3465bba39f86b7db485e2b entfernt, wodurch die Leistung wiederhergestellt wurde.

Wenn man sich 26.1 ansieht, hat sich der Code etwas verschoben, aber compileFunction und der Fallback sind immer noch vorhanden. So:

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

dh das Entfernen des compileFunction Zweigs ( Patch ) bringt 26.1 zurück auf die Laufzeit von 24.9. Ich bin sicher, das ist nicht die Lösung, aber zumindest haben wir etwas, womit wir arbeiten können.

Als weiterer Datenpunkt benötigt unsere jest Suite derzeit mit [email protected] etwa 2767 Sekunden und in unserem Update MR etwa 3497 Sekunden, was einer Steigerung von etwa 27 % entspricht.

Danke für all die großartige Arbeit, liebes Team, ich hoffe, dass die detektivischen Fähigkeiten von @wurstbonbon Ihnen helfen können, diesen Rückschritt zu beheben!

@wurstbonbon danke, dass hast ! Sehr interessant, dass compileFunction langsamer ist... Das sollte bedeuten, dass Sie einfach eine benutzerdefinierte Testumgebung verwenden können, anstatt einen Patch anzuwenden.

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

class MyNodeEnv extends NodeEnv {}

delete MyNodeEnv.prototype.compileFunction;

module.exports = MyNodeEnv;

(und das gleiche für jsdom env). Kannst du bestätigen?

Es klingt jedoch seltsam, dass es ein solcher Engpass ist - Node selbst hat vor 18 Monaten auf die Verwendung umgestellt: https://github.com/nodejs/node/pull/21573. Es ist also wahrscheinlich etwas Seltsames, das wir auf unserer Seite machen. Das verlinkte https://github.com/nodejs/node/issues/26229 ist jedoch sehr interessant - müssen wir vielleicht noch etwas Caching auf unserer Seite machen?

@SimenB Ich habe gerade etwas Ähnliches wie diese benutzerdefinierte

Ich musste jedoch MyNodeEnv.prototype.getVmContext = null; , weil ich mit jest 26 teste und es sieht so aus, als ob es jetzt nach if (typeof this._environment.getVmContext === 'function') { sucht. Ich bin mir jedoch nicht sicher, ob dies andere Probleme verursachen könnte.

Dies sind die Ergebnisse, die ich nach einigen Durchläufen sehe:

Jest 26 w/testEnvironment: "node" => ~280s
Jest 26 mit benutzerdefinierter Testumgebung => ~210s
Witz 24 => ~160s

Lassen Sie mich wissen, wenn ich mit anderen Informationen oder etwas anderem helfen kann!

Wie erwartet führt die benutzerdefinierte Umgebung zu der gleichen Beschleunigung für hübschere.

Ich habe es auch in unserer Codebasis ausprobiert, wo der Unterschied ~270s vs ~200s beträgt, also nur etwa 25% und keine 40%ige Reduzierung. Leider kann ich unsere Tests mit jest 24 nicht durchführen, da wir uns auf die neuen modernen Timer verspotten.

Ich habe in meinem obigen Beispiel ein delete übersehen, tut mir leid.

Ich frage mich, ob es ausreicht, die kompilierten Funktionen nur manuell zwischenzuspeichern - könnten Sie versuchen, diesen Patch anzuwenden? (sowohl transpiliertes JS als auch die hier enthaltene TS-Quelle)

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.',
       );

Ich dachte, das könnte der Trick sein.

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);
}

Es verbessert die Leistung ein wenig, aber Script ist immer noch viel schneller.

Habe die Empfehlung von https://gitlab.com/gitlab-org/gitlab/-/merge_requests/33252/diffs?commit_id=6d633c88caf70f712fa0ccaac42d952976161ec6

Obwohl es die Leistung etwas verbessert hat, ist es immer noch erheblich langsamer als bei jest 24.x:

• Jest 24.x: 2580 Sekunden Gesamtlaufzeit unserer Scherztests
• Jest 26.x: 3166 Sekunden Gesamtlaufzeit unserer Scherztests

@leipert Hast du zufällig versucht, die jsdom-Umgebung auf 14 herunterzustufen?

yarn add test-environment-jsdom-fourteen --dev + "testEnvironment": "test-environment-jsdom-fourteen" in deiner jest-Konfiguration. Dies scheint für uns immer noch für den Großteil der Verlängerung der Laufzeit verantwortlich zu sein (erhöht 40-50%), aber es sieht so aus, als ob mehrere Regressionen im Spiel wären.

@pleunv Mit jest 24.x sind wir auf jsdom 16 mit jest-environment-jsdom-sixteen , wir mussten aufgrund einiger Probleme beim Testen von Webkomponenten ein Upgrade durchführen. Also die einzige Änderung, die wir vornehmen: jest 24.x + jest-environment-jsdom-sixteen -> jest.26x + jest-environment-jsdom , also ändert sich die jsdom-Version nicht einmal.

Eröffnet https://github.com/nodejs/node/issues/35375 Upstream über das von @wurstbonbon gefundene Problem

@SimenB sind Ihnen praktikable Alternativen zu Micromatch bekannt? Dieses Repo ist jetzt seit über einem halben Jahr still, und wichtige Probleme, die Jest betreffen, wie https://github.com/micromatch/micromatch/issues/179, sind noch offen.

Nicht wirklich, es ist das, was die meisten Bibliotheken verwenden. Könnte mir zB Minimatch anschauen, aber ich bezweifle, dass es machbar wäre

@SimenB Was macht Micromatch besser als alle Alternativen?

Basierend auf dem Feedback in dem von mir geöffneten Problem denke ich, dass wir vorerst wieder Script da es anscheinend ein wenig Arbeit in Node braucht, um es dort zu beheben.

@leipert @wurstbonbon oder sonst jemand, kannst du diesen Patch in deinem node_modules/jest-runtime/build/index.js ausprobieren?

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) {

Ich habe den Patch getestet, um Script in unseren Testsuiten zu verwenden, und hier ist das Ergebnis, zu dem ich gekommen bin
Die Zeit ist in min:sec

Name | Suite 1 | Suite 2 | Suite 3 | Suite 4
-- | -- | -- | -- | --
Witz 24 | 3:25 | 3:30 | 3:29 | 0:53
Witz 26 gepatcht | 3:32 | 4:36 | 3:48 | 0:53
Witz 26 ungepatcht | 5:10 | 6:12 | 5:11 | 1:07
26 gepatcht vs 24 | 4% | 31% | 9% | 1%
26 ungepatcht vs 24 | 52% | 76% | 49% | 27%
26 gepatcht vs ungepatcht | 46% | 35% | 36% | 25%

immer noch interessant, dass v26 sich gegenüber v24 immer noch nicht verbessert...

Danke @Cellule! Das reicht mir - ich mach mal ne PR wenn ich etwas Zeit habe

Tolles Zeug! Bleibt dann nur noch das Micromatch-Problem, hoffentlich wird das Repo wieder aktiv gewartet.

Übrigens, es gibt auch eine Perf-Regression in JSDOM, nehme ich an. Wie ich solche Tests in einem großen Webprojekt gemacht habe. Es werden keine oben genannten Patches angewendet.
Und so sah es aus.

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)

Sicherlich ist dies ein super vage und instabiler Leistungsbericht, bei dem ich bleiben muss, aber ich denke, jede Eingabe hilft :)

https://github.com/facebook/jest/releases/tag/v26.5.0 hat die vm.Script Änderung hier besprochen

(Edit: nach weiteren Läufen aktualisiert)

Vorläufige Ergebnisse derselben Testsuite:

Witz 26.5
Kalt: 59,992
Heiß: 43.976

Witz 26.4:
Kalt: 90.213
Heiß: 47.408

Eine sehr deutliche Beschleunigung bei Kaltläufen <3

Und hier sind die Ergebnisse mit meiner Testsuite:

Witz 26.5
Kalt: 149s

Witz 26.4
Kalt: 226s

Tolle Neuigkeiten 🙂 Ich denke, wir sind dann nur noch bei der Micromatch-Regression

Wenn Sie npm-force-resolutions um Micromatch 3 zu installieren. Es funktioniert möglicherweise nicht in [email protected]

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

Fehler beim Ausführen des Tests:

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 Vielen Dank für das Update. Es spart uns 20% der Laufzeit auf Travis nach dem Update auf [email protected]

Unsere Ergebnisse:

Es ist v26.5

• 323,98s
• 321,24s

Es ist v24.9

• 262.17s
• 275,96 s

Danke @SimenB! Das ist großartig. Unsere Ergebnisse für unsere ~22000 Tests in ~2000 Suiten:

• Spaß 24.x: 2864 s
• Witz 26.5.2: 2967 s

Dies ist etwa 3% langsamer und liegt somit im Fehlerbereich, verglichen mit der zuvor gesehenen Verlangsamung von ~27 %. Danke, jetzt müssen wir nur noch zusammenführen: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/33252#note_425616404

Ich wollte nur anmerken, dass alle Probleme mit "Haufen zu wenig Speicher" , die ich zuvor hatte, nach dem Upgrade auf Jest 26.5.2 und Node 14 (vorher auf Node 10) verschwunden sind. Ich bin mir nicht sicher, wie viel des Problems von Jest vs. von Node verursacht wurde, aber wenn andere ähnliche Probleme sehen, versuchen Sie, auf beide zu aktualisieren.

UPDATE : Egal. Ich bekomme wieder OOM-Fehler. Ich denke, es ist genau an der Grenze dessen, was mein Laptop verarbeiten kann und die ersten paar Durchläufe waren gut, aber jetzt stirbt es wieder. Muss noch am 24.xx bleiben :(

Wenn es jemanden interessiert, habe ich ein DOM erstellt, das im Vergleich zu JSDOM eine sehr gute Leistung hat. Es hat Unterstützung für Jest.

| Bedienung | JSDOM | Happy DOM |
| ------------------------------------ | -------- | --------- |
| Importieren / Erfordern | 333 ms | 45 ms |
| HTML parsen | 256 ms | 26 ms |
| HTML serialisieren | 65 ms | 8 ms |
| Benutzerdefiniertes Element rendern | 214 ms | 19 ms |
| querySelectorAll('tagname') | 4,9 ms | 0,7 ms |
| querySelectorAll('.class') | 6,4 ms | 3,7 ms |
| querySelectorAll('[Attribut]') | 4,0 ms | 1,7 ms |
| querySelectorAll('[class~="name"]') | 5,5 ms | 2,9 ms |
| querySelectorAll(':nth-child(2n+1)') | 10,4 ms | 3,8 ms |

Link zum Projekt:
https://github.com/capricorn86/happy-dom/

@capricorn86 Sieht gut aus. Ist es spezifikationskonform?

@capricorn86 Sieht gut aus. Ist es spezifikationskonform?

Danke @milesj!

Die implementierte Funktionalität wurde gemäß den Spezifikationen implementiert, es gibt jedoch noch keinen detaillierten Überblick darüber, welche Spezifikationen abgedeckt werden. Ich überlege, das hinzuzufügen. Alle Funktionen werden jedoch durch Unit-Tests abgedeckt.

Das ursprüngliche Ziel des DOM war es, Webkomponenten serverseitig mit guter Performance rendern zu können, wie ich sie für einige andere Projekte benötigte.

FWIW, ich habe gerade versucht, unser Projekt von react-scripts@3 mit Jest 24.9 auf @react-scripts@4 mit Jest 26.6 zu erhöhen.

Unsere Server-API-Testsuite wurde zuvor in etwa 180-190 Sekunden ausgeführt. Nach dem Wechsel zu Jest 26.6 dauerte es konstant etwa 220 Sekunden. Ich habe sogar versucht, die Auflösung von minimatch auf 4.0.2 erzwingen. Das Umschalten des Testläufers auf jest-circus schien ein paar Sekunden zu verkürzen, aber insgesamt scheint 26,6 merklich langsamer zu sein.

react-scripts@4 verwendet standardmäßig jest-circus , fwiw. Es ist auch micromatch wir verwenden, nicht minimatch . Anscheinend haben wir jedoch das Zurückrollen von micromatch über #10131 abgebrochen, daher ist es nicht mehr so ​​einfach zu testen, ob dies die Ursache für die Regression ist

@SimenB : Wir haben ein seltsames Migrations-Setup-ATM - es ist eine ältere MEAN / AngularJS-App, die ich konvertiert habe, um sie mit CRA zu erstellen . Die Testkonfiguration ist unsere eigene, im Gegensatz zur integrierten CRA-Jest-Konfiguration - wir nutzen nur die Tatsache, dass CRA mit Jest als Abhängigkeit geliefert wird.

Ich habe meine Arbeitsbox nicht vor meinem Geldautomaten, daher kann ich mich jetzt nicht erinnern, ob ich wirklich micromatch gemeint habe oder ob ich mich dort wirklich auf den falschen Paketnamen konzentriert habe :) Ich muss nachsehen nächste Woche wieder dabei.

Mir ist gerade aufgefallen, dass v26 in iTerm _viel_ langsamer läuft als im Standardterminal von macOS. Bei einem Satz von 6500 Tests erhalte ich durchweg die folgenden Ergebnisse:

• v24, Terminal: ~90s
• v24, iTerm2: ~90s
• v26, Terminal: ~110s
• v26, iTerm2: ~150s

Dies hat mich ein wenig umgehauen, nachdem ich monatelang verschiedene Dinge ausprobiert hatte, um die Verlangsamung zu beheben. Besteht die Möglichkeit, dass jemand mit Perf-Problemen auf einem Mac dies ausprobieren kann? Wohlgemerkt , dies ist mit

@pleunv Ich glaube, dies könnte zusammenhängen: https://github.com/facebook/jest/pull/9294. Mir ist aufgefallen, dass Hyperlinks iTerm2 auf meinem Computer verlangsamen, wodurch es abgehackt wird. Aber ich habe weder die Gesamtgeschwindigkeit der Ausführung untersucht noch eine andere Person gefunden, die Probleme damit hatte.

Heureka. Die Suche nach "iTerm" brachte mich zu dieser PR . Ich hatte diese Unterstreichungen schon einmal bemerkt und wusste nicht, dass es sich um Hyperlinks handelte. Nachdem ich diese PR gesehen hatte, deaktivierte ich Hyperlinks in iTerm, was meine Laufzeit auf 130 Sekunden verkürzte. Nachdem ich den Code aus dem PR angewendet und die Hyperlinks entfernt habe, bin ich wieder bei 120s. Gesundheit leicht restauriert.

Gibt es eine Chance, dass PR wieder reinkommt?

edit: @thymikee hat mich geschlagen

@pleunv Ich werde versuchen, diese Woche etwas Zeit zu finden, um es zurückzubringen. Obwohl die eigentliche Sache darin besteht, dies für iTerm zu beheben, da andere Terminals, z. B. unter Linux, keine Probleme mit Hyperlinks haben. Würde es Ihnen etwas ausmachen, ein Problem beim iTerm-Projekt einzureichen?

Ich habe gerade diese Änderung vorgenommen und es gab 1s für eine einzelne Testdatei. Und Sie können immer noch auf die URL klicken, sie ist nur nicht mehr unterstrichen.

Dies kann bei größeren Auflagen enorm sein. ️

//bearbeiten
Komisch, dass es vorher keinen Unterschied machte, ob es sich um Iterm oder Terminal handelte. Nach der Änderung geht es bei mir schneller.

@pleunv Ich werde versuchen, diese Woche etwas Zeit zu finden, um es zurückzubringen. Obwohl die eigentliche Sache darin besteht, dies für iTerm zu beheben, da andere Terminals, z. B. unter Linux, keine Probleme mit Hyperlinks haben. Würde es Ihnen etwas ausmachen, ein Problem beim iTerm-Projekt einzureichen?

Ich habe hier ein Problem erstellt (sie sind auf GitLab). Wenn jemand zusätzliche Details oder ein Reproprojekt hat, kann er gerne hinzufügen.

Ich habe in der Zwischenzeit noch etwas experimentiert und festgestellt, dass Hyperlinks im Allgemeinen keinen großen Unterschied machen, wenn sie nur mit einer kleineren Teilmenge von Tests (ein paar Dutzend Testdateien) ausgeführt werden. Wenn wir es jedoch mit unserem vollständigen Set (700 Dateien) ausführen, ist die Auswirkung sehr gut messbar.

Ich habe auch den Eindruck, dass die Konsolenausgabe von Jest auf lange Sicht wirklich fehlerhaft/auffällig wird. Die Fortschrittslinien am unteren Rand sind beispielsweise mehr versteckt als sichtbar.