Der Test selbst, der Bericht und der Rest der Seite sind vorerst auf Englisch.
Für Entwickler
Der Build ist langsam. Liegt es am Code oder an der Kühlung?
Kompilieren und Testsuiten lasten jeden Kern minutenlang aus und bestrafen Speicherlatenz. SystemCheck misst beides, wiederholbar, damit ein langsamer Build dem Richtigen angelastet wird.
Was der Bericht dir sagt
Drei Zahlen, jede mit ihrer Deutung.
Dauerdurchsatz auf allen Kernen
ops/s
Ein Worker pro logischem Kern über die Länge des Laufs. Das ist die Zahl, die ein paralleler Build sieht, nicht der Single-Core-Boost auf der Verpackung.
Speicherlatenz
ns
Die Rundreise zum Speicher und zum Cache. Linker, Paketmanager und alles Pointer-lastige laufen mit dieser Geschwindigkeit.
Wiederholbarkeit
%
Lass die CPU-Stufe zweimal laufen und der Bericht gibt die Streuung an. Eine Änderung innerhalb der Streuung ist keine Änderung, was auch immer der Build-Timer gesagt hat.
Die Diagnose
Die Form der Kurve, gelesen für deinen Fall.
01Gehalten
Die Maschine ist nicht das Problem. Schau auf den Build-Graphen, den Cache und was sonst noch läuft.
02Eine einzelne Stufe nach unten
Ein Power-Limit, meist die Dauerleistung eines Laptops. Lange Builds laufen auf dem Niveau nach der Stufe, nicht davor.
03Unruhig
Etwas anderes ist auf den Kernen. Ein Indexer, ein Sync-Client, ein Container, der nie ruht. Die Kernanteil-Zahl des Berichts nennt Starvation, wenn er sie sehen kann.
Jede Klasse kommt mit einer angegebenen Konfidenz und dem Rauschboden der Messung selbst. Wie die Form gelesen wird
Wo ein Browser aufhört
Was er dir nicht sagen kann.
- Keine Takte pro Kern: Der Browser sieht Durchsatz, nicht Frequenz. Die Kurve zeigt die Wirkung einer Taktänderung, ohne die Megahertz zu nennen.
- Keine Konkurrenzerkennung innerhalb eines Laufs: Ein Programm, das sich still die Kerne teilt, ist von einer langsameren Maschine nicht zu unterscheiden. Der Vorher-Nachher-Vergleich ist das Instrument dafür.
- Kernanzahl wie gemeldet: Firefox deckelt sie, Safari deckelt sie bei acht, und der Bericht sagt, welche Anzahl er verwendet hat.
Welcher Lauf
Standard, 3 Minuten.
Für eine wiederholbare Basislinie liefert der Standard-Lauf, wiederholt, schnell eine Streuung. Nutze den Deep-Lauf einmal, um auf einem Laptop das eingependelte Niveau zu finden.
Beide Arten sind kostenlos. Die Wahl triffst du auf dem Einrichtungsbildschirm.
Fragen
So gestellt, wie man sie stellt.
- Warum ist mein Build langsamer, als der Benchmark vermuten lässt?
- Build-Zeiten spiegeln den Dauerdurchsatz auf allen Kernen und die Speicherlatenz wider, nicht den Single-Core-Boost, mit dem die meisten Benchmarks werben. Der Test meldet beides, und die Kurve zeigt, ob die Maschine ihr All-Core-Niveau über die Länge eines Builds hält oder nach dem Boost-Fenster eine Stufe nach unten macht.
- Kann ich damit zwei Maschinen vergleichen?
- Ja, anhand der gemessenen Zahlen: Dauerdurchsatz, Abfall, Speicherbandbreite und -latenz, Frametime. Lass jede Maschine zweimal laufen, damit der Bericht die Streuung angeben kann; ein Unterschied innerhalb der Streuung ist Rauschen.
- Beeinflussen Docker oder eine VM das Ergebnis?
- Alles, was während des Laufs die Kerne nutzt, senkt den Durchsatz und erhöht das Rauschen, und der Bericht markiert ausgehungerte Worker, wenn er sie sehen kann. Beende vor einer Basislinie, was du kannst, und lass dann mit der üblichen Last noch einmal laufen, um deren Kosten zu messen.