Wie man die Geschwindigkeit verschiedener Programmversionen unter Windows korrekt vergleicht

Sie möchten unter Windows die Programmversionen A und B vergleichen. Das Schlechteste, was Sie dabei tun können, ist, auf derselben Maschine jede Version einmal auszuführen und zu sagen: „B scheint 8 % schneller zu sein.“

Diese 8 % könnten tatsächlich ein Codeunterschied sein. In Wirklichkeit liegt es aber oft an power mode, power plan, Wärme, Hintergrund-Updates, Suchindexierung, Virenscan, Affinität, Ausführungsreihenfolge oder Cache-Zustand — eine klassische Geschichte beim Benchmarking unter Windows. Es wird zur unauffälligen Kleinarbeit, die Bedingungen eine nach der anderen auszuräumen.

Dieser Artikel fasst zusammen, wie man die Ausführungsgeschwindigkeit unterschiedlicher Versionen eines Programms unter Windows möglichst nah am reinen Codeunterschied vergleicht. Als Zielsystem wird vor allem Windows 11 angenommen, aber das meiste — powercfg, start und Ähnliches — funktioniert unter Windows 10 genauso.

Begriffe, die man vorab kennen sollte

Im Text tauchen einige Begriffe unübersetzt auf Englisch auf. Damit Sie beim ersten Auftreten nicht stolpern, hier vorab eine Übersicht.

Fazit zuerst

Auf den Punkt gebracht, sind es diese sechs Kniffe, um die Reproduzierbarkeit zu erhöhen.

1. Zuerst festlegen, „was Sie vergleichen wollen“ Ob Sie den Codeunterschied oder das reale Nutzererlebnis sehen wollen, ändert, welche Umgebungsfaktoren Sie angleichen müssen.

2. power mode und power plan getrennt dokumentieren Behandelt man das unter Windows nachlässig, wird der Vergleich schnell zu einem Vergleich der Energiesparrichtlinien des Betriebssystems.

3. Den kalten ersten Durchlauf vom eingeschwungenen Zustand nach dem Aufwärmen trennen „Nur der erste Durchlauf ist schnell“ oder „nur die spätere Hälfte ist langsam“ ist nicht ungewöhnlich.

4. Abwechselnd im Muster A→B→A→B durchlaufen Lässt man A komplett durchlaufen und dann erst B, holt man sich die Schieflage durch Wärme und Hintergrundzustand ein.

5. Nicht nur den Mittelwert, sondern auch Median und Streuung betrachten Ein einzelner Ausreißer zerstört das Bild. Der Mittelwert ist zerbrechlicher, als man denkt.

6. Ist der Unterschied klein, mit ETW / WPR bis zur Ursache graben Diskutiert man nur nach Gefühl, bleiben beide Seiten unbelegt und reden aneinander vorbei.

Zuerst festlegen, was Sie vergleichen wollen

„Geschwindigkeitsvergleich“ klingt nach einer Sache, tatsächlich gibt es aber zwei Arten.

1. Ein Vergleich, der den Codeunterschied zeigen soll

Sie möchten wissen, ob die Implementierung selbst schneller geworden ist — durch eine Algorithmusänderung, eine Datenstrukturänderung, Compiler-Optimierung, ein Runtime-Update und Ähnliches.

In diesem Fall reduzieren Sie Umgebungsrauschen so weit wie möglich. Eine dedizierte Bench-Sitzung, ein fixierter power mode, Benachrichtigungen aus, Suchindexierung und Synchronisierung unterdrückt, notfalls sogar bis hin zu clean boot.

2. Ein Vergleich, der das reale Nutzererlebnis zeigen soll

Sie möchten wissen, wie schnell sich das für Nutzer nach der Veröffentlichung im gewöhnlichen Windows-Alltag tatsächlich anfühlt.

In diesem Fall dürfen Sie das in der Realität vorhandene Rauschen nicht vollständig entfernen. Ein Vergleich in einer „plausiblen Alltagsumgebung“ — mit OneDrive-Synchronisierung, Defender, Benachrichtigungen und normalen Stromeinstellungen — liefert ein realitätsnäheres Ergebnis.

Vermischt man diese beiden, verdreht sich die Schlussfolgerung. „Im Labor 12 % schneller, in der Realität aber im Rauschen“ oder „in der Realität schneller, aber bei der CPU-Zeit unverändert“ — solche Dinge passieren dabei ganz normal.

Die Hauptursachen für Schwankungen unter Windows

Zunächst eine grobe Übersicht darüber, was Ergebnisse zum Schwanken bringt.

Kurz gesagt: Selbst „dieselbe Windows-Maschine“ ist ein anderes Experiment, wenn die Bedingungen nicht angeglichen sind.

power mode und power plan getrennt betrachten

Das ist ziemlich wichtig.

Unter Windows gibt es sowohl den power mode der Einstellungen-App als auch den herkömmlichen power plan (den über powercfg sichtbaren Energieplan). Da sie sich optisch ähneln, werden sie gern in einen Topf geworfen — geht man damit nachlässig um, verwischt der Vergleich.

In der Windows-Einstellungen-App wählen Sie den power mode unter Settings > System > Power & battery. Microsofts Dokumentation zufolge lassen sich Best power efficiency, Balanced und Best performance getrennt für Plugged in / On Battery umschalten. Darüber hinaus wirkt sich eine Änderung des power mode auch auf dahinterliegende stromverwandte Einstellungen und das Verhalten von PPM (Processor Power Management) aus. Das heißt, allein dieser Unterschied kann die Richtlinie für Core Parking und Leistungsskalierung ändern.

Der power plan hingegen ist der traditionelle Energieplan wie Balanced, High performance und so weiter. Er lässt sich mit powercfg /list und powercfg /getactivescheme abrufen.

Verwirrend wird es dadurch, dass es unter Windows sowohl die power-mode-Overlay als auch den power plan gibt. Als Diagramm sieht die Beziehung so aus.

flowchart TB
    subgraph upper["Obere Schicht: Power mode - Overlay"]
        direction LR
        M1["Best power efficiency"]
        M2["Balanced"]
        M3["Best performance"]
    end

    subgraph lower["Untere Schicht: Power plan - Energieplan"]
        direction LR
        P1["Balanced"]
        P2["High performance"]
        P3["custom plan"]
    end

    UI["Einstellungen-App<br/>Power mode unter Power and battery"] --> upper
    CLI["Umschaltung per powercfg /setactive"] --> lower
    upper --> PPM["Tatsächlich wirksame Stromeinstellung<br/>PPM und Grafik-Untergruppen"]
    lower --> PPM
    AC["AC-Netzteil oder Akku"] --> PPM
    PPM --> RESULT["Obergrenze der Taktfrequenz / Core Parking / Leistungsskalierung"]

Betrachtet man nur die obere oder nur die untere Schicht, lässt sich das tatsächliche Verhalten nicht bestimmen. Halten Sie daher im Benchmark-Ergebnis mindestens Folgendes fest:

• AC-Netzteil oder Akku
• Welcher power mode
• Welcher aktive power plan

Ein Benchmark-Ergebnis, das diese drei Angaben nicht enthält, lässt sich später nicht mehr auf seine Bedingungen zurückführen.

Zuerst zu fixierende Stromversorgungsbedingungen

1. Notebooks unbedingt mit AC-Netzteil vergleichen Akkubetrieb bringt leicht unbeabsichtigte Drosselungen mit sich.

2. Den power mode fixieren Für Bench-Zwecke zuerst Best performance ausprobieren.

3. Den aktiven power plan dokumentieren Den aktuellen Wert mit powercfg festhalten.

powercfg /list
powercfg /getactivescheme

Die Ausgabe von powercfg /list wird in Microsofts Dokumentation in folgender Form gezeigt. Die aktive Zeile trägt am Ende ein *. In deutscher Umgebung erscheinen Überschrift und Plannamen auf Deutsch.

Existing Power Schemes (* Active)
-----------------------------------
Power Scheme GUID: {guidPlan1}  (Balanced) *
Power Scheme GUID: {guidPlan2}  (Power saver)

Übertragen Sie die hier ausgegebene GUID unverändert in das Feld power_plan Ihrer Ergebnisdatei. Entscheidend ist, die GUID statt des Namens festzuhalten — denn hinter demselben Namen „Balanced“ kann sich ein anderer, duplizierter oder angepasster Plan verbergen.

1. Bei Bedarf auf High performance umschalten

# Balanced
powercfg /setactive 381b4222-f694-41f0-9685-ff5bb260df2e

# High performance
powercfg /setactive 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c

Lässt sich der power mode per Befehl umschalten?

Hier hakt es leicht. In der veröffentlichten Liste der Kommandozeilenoptionen von powercfg gibt es keine Option, um den power mode (das Overlay) selbst neu auszuwählen. Die reguläre Vorgehensweise zum Umschalten ist die Einstellungen-App unter Settings > System > Power & battery.

powercfg unterstützt dagegen das Lesen und Schreiben der Einstellungswerte des Overlay-Schemas. Die Dokumentation hält dazu Folgendes fest:

• Übergibt man powercfg /q den Alias und die Untergruppe des Overlays, lassen sich dessen Einstellungen auslesen
• powercfg /setacvalueindex und /setdcvalueindex lassen sich auch auf Overlay-Schemata anwenden
• Wird kein Schema angegeben, ist das aktuell aktive Overlay das Ziel (ohne Overlay der aktuelle power plan)
• Die Liste der Aliase lässt sich mit powercfg /aliases abrufen

Per Befehl lässt sich also nur „den Inhalt des gerade wirksamen Overlays lesen und anpassen“, nicht aber „welches Overlay gewählt ist“ ändern. Für ein reproduzierbares Bench-Verfahren ist es realistisch, den power mode manuell in der Einstellungen-App zu fixieren und den Wert im Ergebnis zu dokumentieren. Halten Sie im Verfahrensdokument ausdrücklich fest: „power mode = Best performance eingestellt“, und prüfen Sie es vor jeder Ausführung auf dem Bildschirm.

„High performance taucht nicht auf“ ist ganz normal

Auch hier stolpert man leicht. Microsofts Dokumentation zufolge sind bei Modern-Standby-fähigen Geräten nur Balanced oder von Balanced abgeleitete Pläne zulässig. Statt „High performance ist nicht zu finden, ist das kaputt?“ kann es also einfach sein, dass das Gerät genau so konstruiert ist.

Microsoft weist außerdem darauf hin: Lässt sich der power mode nicht ändern, könnte ein custom power plan ausgewählt sein — versuchen Sie deshalb zuerst, Balanced auszuwählen. Reagiert die power-mode-Oberfläche nicht, ist das der erste Verdacht.

Hintergrundrauschen beseitigen

Windows arbeitet auch dann im Hintergrund weiter, wenn Sie in Ruhe messen möchten — Updates, Indexierung, Scans. Zunächst reduzieren wir diese Menge.

Zuerst neu starten und warten, bis es sich beruhigt

Nach einer Einstellungsänderung einmal neu starten und nicht sofort nach der Anmeldung loslegen, sondern einige Minuten warten. Direkt nach dem Start toben Updates, Indexierung, Synchronisierung, Defender und diverse residente Prozesse noch.

Für strenge Vergleiche clean boot verwenden

Microsoft dokumentiert ein Verfahren, um per clean boot eine minimale Startkonfiguration zu erreichen: Nicht-Microsoft-Dienste in msconfig stoppen und Autostart-Apps im Task-Manager deaktivieren.

Das ist sehr wirksam, um Rauschen zu reduzieren. Es entfernt sich jedoch von der Alltagsumgebung und eignet sich daher für „Laborvergleiche, die den Codeunterschied zeigen sollen“.

Benachrichtigungen zum Schweigen bringen

Windows-Benachrichtigungsbanner wirken unscheinbar, sind aber überraschend störend. Neben der visuellen Ablenkung können sie Ausführungszeitpunkt, Fokus und Hintergrund-App-Aktivität verändern.

Aktivieren Sie Do not disturb manuell, oder schalten Sie Benachrichtigungen zumindest während des Benchmarks aus.

Suchindex und Synchronisierung unterdrücken

Liest das Bench-Ziel viele Dateien, schreibt es viele Artefakte oder baut es den Quellbaum wiederholt neu auf, stechen Suchindexierung und Cloud-Synchronisierung unauffällig zu.

• Das Bench-Verzeichnis von der Suche ausschließen
• Die Synchronisierung von OneDrive / Dropbox / Google Drive anhalten
• Browser, Teams, Discord, Slack schließen

Das wirkt nicht spektakulär, kann aber, wenn es wirkt, ziemlich viel ausmachen.

Ein Vergleich, der die Wärme nicht angleicht, vergleicht meist nur die Wärme

CPU und GPU ändern ihre Taktfrequenz je nachdem, ob sie kalt oder aufgewärmt sind. Selbst bei identischem Code ändern sich also die Bedingungen von Durchlauf zu Durchlauf. Besonders bei Notebooks, dünnen Mini-PCs und kleinen Desktops fällt das deutlich auf.

Einzuhaltende Regeln

• Die Raumtemperatur möglichst konstant halten
• Die Position des Notebooks fixieren
• Netzteil, Dockingstation und externe Bildschirmkonfiguration fixieren
• Vor dem Benchmark keine schwere Arbeit ausführen
• Den ersten Durchlauf und den eingeschwungenen Zustand getrennt messen

Die Ausführungsreihenfolge abwechseln

Vermeiden Sie es, A zehnmal und dann B zehnmal auszuführen. Dabei schlägt die Schieflage durch Wärme, Cache und Hintergrundaktivität zu.

Empfehlenswert ist eine dieser Varianten:

• A B A B A B ...
• A B B A A B B A ...
• Eine Zufallsreihenfolge vorab erzeugen und in dieser Reihenfolge durchlaufen

Was Sie messen, ändert die Bedeutung von „schnell“

Presst man „schnell“ in eine einzige Zahl, geht das meistens schief. Die drei repräsentativen Messgrößen, die man unter Windows betrachten sollte:

1. Wall-clock time (Echtzeit)

Die Zeit, die der Nutzer wartet. Sie liegt dem End-to-End-Empfinden am nächsten, deshalb ist das der erste Wert, den man sich ansieht.

Unter Windows lässt sich QueryPerformanceCounter (QPC) für hochauflösende Zeitmessung nutzen. In managed code ist die Stopwatch-Familie die übliche Wahl. DateTime.Now millisekundengenau abzulesen, ist doch ziemlich schutzlos.

2. CPU time (Benutzer- + Kernel-Zeit)

Die über GetProcessTimes abrufbare Zeit, die der Prozess tatsächlich auf der CPU verbracht hat.

Das ist nützlich, um die Recheneffizienz zu betrachten. Wird zum Beispiel die wall-clock-Zeit besser, ohne dass sich die CPU time ändert, könnten Cache, I/O, Wartezeit oder Scheduling die eigentliche Ursache sein.

3. Cycle count (CPU-Zyklenzahl)

QueryProcessCycleTime liefert die CPU-Zyklenzahl des gesamten Prozesses.

Auch das ist eine Kennzahl für CPU-Arbeit, zeigt aber eine andere Facette als die wall-clock-Zeit. Besonders nützlich, wenn Sie wissen wollen, „ob die Wartezeit gleich bleibt, aber der Rechenanteil leichter geworden ist“.

priority, affinity und NUMA sind letzte Mittel

Diese Stellschrauben können wirken. Aber gerade weil sie wirken, erzeugt man leicht ein anderes Phänomen, wenn man von Anfang an daran dreht.

Zuerst ganz normal messen

Zeigt sich der Unterschied schon im Standardzustand, hat dieser Unterschied selbst einen Wert. Setzt man von vornherein /high oder /affinity ein, bringt man „Bedingungen, die im echten Windows nicht auftreten“ ins Spiel.

Wenn Sie sie verwenden, den Zweck klären

• /high: Sie wollen weniger Störung durch andere Prozesse
• /affinity: Sie wollen die CPU-Zuteilung für den Vergleich fixieren
• NUMA-Steuerung: Sie wollen bei großen Maschinen auch die Speicherlokalität angleichen

Der Windows-Befehl start lässt sich mit priority class und affinity mask starten.

start "" /high /wait myapp.exe --bench case1.json
start "" /affinity F /high /wait myapp.exe --bench case1.json

/realtime aber lassen

/realtime lässt sich verwenden, sollte aber nicht verwendet werden. Es wirkt weniger als Rauschunterdrückung und eher als Erzeuger neuer Zwischenfälle.

Empfohlenes Messverfahren

Fassen wir das bisher Gesagte zu einem praxistauglichen Verfahren zusammen.

Laborlastiges Vergleichsverfahren

1. Die Vergleichsobjekte fixieren
   • commit hash / Build-Nummer
   • Compiler- / Runtime-Version
   • Debug / Release
   • Logging, Assertions, Tracing an/aus
2. Die Maschinenbedingungen fixieren
   • Windows-Build
   • BIOS-/UEFI-Version
   • Treiberversion
   • AC-Netzteil
   • Raumtemperatur, Aufstellung
3. Die Stromversorgungsbedingungen fixieren
   • Den power mode festlegen
   • Den aktiven power plan dokumentieren
4. Neu starten
5. Vor dem Benchmark einige Minuten warten
6. Bei Bedarf clean boot
7. Ein warm-up einbauen
8. A / B abwechselnd durchlaufen
9. Genug Wiederholungen einplanen
10. Median, Minimum, Maximum, p95 festhalten
11. Rohdaten speichern
12. Bei kleinem Unterschied ETW / WPR aufzeichnen

Wie oft man durchlaufen sollte

Auch für Punkt 9, „genug Wiederholungen einplanen“, legen wir einen Richtwert fest. Das Folgende ist keine statistisch strenge Lösung, sondern ein praxistauglicher Kompromiss.

Der Zeitbedarf lässt sich als Laufzeit eines Durchlaufs × Anzahl der Durchläufe × Anzahl der Versionen + warm-up abschätzen. Bei 30 Sekunden pro Durchlauf, jeweils 30 Durchläufen für A / B, ergibt das mit warm-up etwa 35 Minuten. Ist das nicht praktikabel, ist es sinnvoller, das Messobjekt kleiner zu schneiden (nur den schweren Arbeitsschritt herauszulösen), als die Anzahl der Durchläufe zu reduzieren.

Wer nicht weiß, wo er aufhören soll: Die Anzahl der Durchläufe schrittweise erhöhen und beobachten, wie sich der Median entwickelt — aufhören, sobald sich trotz weiterer Durchläufe nichts mehr bewegt. Das ist die nachvollziehbarste Vorgehensweise.

Punkte, die sich zu notieren lohnen

In der Bench-CSV oder -JSON sollten mindestens diese Angaben stehen — das zahlt sich später aus.

timestamp,version,scenario,elapsed_ms,user_ms,kernel_ms,cycles,power_mode,power_plan,ac_or_dc,room_temp_c,notes

Falls möglich, sind zusätzlich diese hilfreich.

cpu_package_temp_start_c,cpu_package_temp_end_c,affinity_mask,priority_class,windows_build,driver_version

Bei Benchmarks ist oft wichtiger, später interpretieren zu können, als das reine Messen selbst.

Nicht nur den Mittelwert, sondern Median und Verteilung betrachten

Der Mittelwert ist praktisch, bricht bei Windows-Benchmarks aber leicht zusammen. Ein einziges Mal Defender, eine Benachrichtigung, ein anderer Prozess, der die SSD belastet — das reicht schon, um den Mittelwert zu verzerren.

Empfehlenswert ist diese Kombination:

• Median: Zuerst diesen betrachten
• p95 / p99: Prüfen, ob sich der Tail verschlechtert hat
• min / max: Die Ausreißer betrachten
• Boxplots oder Streudiagramme: Hilfreich, wenn der Unterschied klein ist

Wie man einen aufgetretenen Unterschied liest

Die Interpretation der Ergebnisse fällt leichter, wenn man Kombinationen betrachtet.

Nur wall-clock ist schneller

Möglicherweise eine Verbesserung bei I/O, Wartezeit, Cache oder Scheduling.

CPU time und cycle sinken beide

Es ist wahrscheinlich, dass die Implementierung selbst leichter geworden ist.

Nur der erste Durchlauf ist langsam / schnell

Das ist der cold/warm-Unterschied. Verdächtigen Sie Start, Initialisierung, Cache-Aufbau, JIT.

Wird mit jedem Durchlauf langsamer

Verdächtigen Sie Wärme, Throttling, Speicherdruck, Hintergrundaktivität.

Mit ETW / WPR bis zum „Warum“ graben

Ist der Unterschied klein oder der Grund nicht erkennbar, ist der Weg über Windows’ ETW-Werkzeuge (Event Tracing for Windows) der Königsweg.

Microsofts Windows Performance Recorder (WPR) ist ein ETW-basiertes Aufzeichnungswerkzeug, das im Windows ADK enthalten ist. Es kann CPU, I/O, Kontextwechsel, Seitenfehler und mehr gebündelt erfassen.

Im Minimalfall sieht das so aus.

wpr -start CPU -filemode

REM Hier den Benchmark ausführen

wpr -stop trace.etl

Nach dem Öffnen in WPA sind die zuerst zu betrachtenden Diagramme meist dieselben.

Beim Vergleich ist es üblich, für dasselbe Szenario je eine Trace von A und B aufzuzeichnen und dieselben Diagramme nebeneinander zu betrachten. Aus nur einer Trace lässt sich nicht beurteilen, „ob das nun langsam ist“.

Auf dieser Stufe angekommen, lässt sich nicht mehr nur sagen „B ist 3 % schneller“, sondern mit Begründung: „B hat weniger lock-Wartezeit und eine geringere ready time.“ „A öffnet mehr Dateien und hat einen langsameren cold start.“

Eine Checkliste zum Ausdrucken

Zum Schluss noch in einer Form, die sich direkt in ein Verfahrensdokument einfügen lässt.

Fixieren

• Die Vergleichsobjekte fixiert (commit hash / Build-Nummer / Debug oder Release / Build-Bedingungen wie PGO / Logging und Assertions an oder aus)
• Das Notebook auf AC-Netzteil gestellt
• Den power mode in der Einstellungen-App fixiert
• Den aktiven power plan mit powercfg /getactivescheme geprüft
• Benachrichtigungen gestoppt. Suchindexierung und Cloud-Synchronisierung gestoppt
• Bei Bedarf clean boot durchgeführt
• Neu gestartet und erst nach einigen Minuten begonnen

Ausführen

• Ein warm-up eingebaut
• cold (erster Durchlauf) und warm (eingeschwungen) getrennt gemessen
• A / B abwechselnd oder in Zufallsreihenfolge durchlaufen
• Eine feste Anzahl an Durchläufen ausgeführt (Richtwert siehe Tabelle oben)

Dokumentieren

• Rohdaten mit einer Zeile pro Durchlauf gespeichert (elapsed_ms / user_ms / kernel_ms / cycles)
• AC oder DC, power mode, die GUID des power plan, Windows-Build und Treiberversion festgehalten
• Raumtemperatur und Aufstellung festgehalten
• Auch nicht fixierte Bedingungen notiert

Interpretieren

• Den Median betrachtet. Nicht allein nach dem Mittelwert entschieden
• Mit p95 / p99 den Tail betrachtet
• Mit min / max die Ausreißer geprüft
• Aus der Kombination von wall-clock / CPU time / cycle auf die Ursache geschlossen
• Bei kleinem Unterschied bis zu ETW / WPR gegraben

Zusammenfassung

Beim Vergleich unterschiedlicher Programmversionen unter Windows wirkt nicht der auffällige Trick. Entscheidend ist die folgende, unauffällige, aber für die Reproduzierbarkeit wirksame Disziplin:

• AC / power mode / power plan fixieren und dokumentieren
• cold und warm trennen
• A / B abwechselnd durchlaufen
• Median und Verteilung betrachten
• Bei Bedarf clean boot
• Bei kleinem Unterschied mit ETW / WPR bis zur Ursache graben

Und am wichtigsten: Notieren Sie zusammen mit dem Ergebnis, was Sie fixiert haben und was nicht. Ein Benchmark ist zugleich ein Geschwindigkeitsvergleich und eine Dokumentation der Versuchsbedingungen.

Bei einem Beschleunigungsbericht ohne dokumentierte Bedingungen kann niemand anderes nachprüfen, ob sich dasselbe Ergebnis reproduzieren lässt — es bleiben nur die Zahlen, aber kein Weg zur Reproduktion. Sind die Bedingungen dagegen sauber dokumentiert, hat das Ergebnis auch bei kleinem Unterschied echten Wert.

Referenzen

• Microsoft Support: Change the power mode for your Windows PC
• Microsoft Learn: Power Policy Settings
• Microsoft Learn: Customize the Windows performance power slider
• Microsoft Learn: Powercfg command-line options
• Microsoft Support: How to perform a clean boot in Windows
• Microsoft Support: Notifications and Do Not Disturb in Windows
• Microsoft Support: Search indexing in Windows
• Microsoft Learn: Configure custom exclusions for Microsoft Defender Antivirus
• Microsoft Support: Device Security in the Windows Security App
• Microsoft Learn: QueryPerformanceCounter function
• Microsoft Learn: Acquiring high-resolution time stamps
• Microsoft Learn: GetProcessTimes function
• Microsoft Learn: QueryProcessCycleTime function
• Microsoft Learn: start command
• Microsoft Learn: SetPriorityClass function
• Microsoft Learn: SetProcessAffinityMask function
• Microsoft Learn: Processor Groups
• Microsoft Learn: Windows Performance Recorder
• Microsoft Learn: WPR Command-Line Options
• Microsoft Learn: CPU Analysis in Windows Performance Analyzer - Welches Diagramm wofür.
• Microsoft Learn: Set the Default Power Plan - Beispielausgabe von powercfg -LIST.

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Was sind die Hauptgründe dafür, dass Benchmark-Ergebnisse unter Windows schwanken?

Es gibt mehrschichtige Faktoren: power mode und power plan, Wärme, Hintergrund-Updates, Suchindexierung, Virenscan, Priorität und Affinität, Ausführungsreihenfolge und Cache-Zustand. Selbst auf derselben Windows-Maschine ist es faktisch ein anderes Experiment, wenn diese Bedingungen nicht angeglichen sind. Besonders bei Notebooks ändert sich das Verhalten stark je nachdem, ob sie über AC-Netzteil oder Akku laufen, weshalb Sie unbedingt mit AC-Netzteil vergleichen und die Bedingungen dokumentieren sollten.

Was ist der Unterschied zwischen power mode und power plan?

Power mode ist die in der Einstellungen-App unter Power & battery wählbare Umschaltung zwischen Best power efficiency, Balanced und Best performance, die sich auf dahinterliegende stromverwandte Einstellungen und das Verhalten von PPM (Processor Power Management) auswirkt. Power plan ist der traditionelle, über powercfg abrufbare Energieplan wie Balanced oder High performance. Da es unter Windows beide gibt, müssen Sie im Benchmark-Ergebnis mindestens drei Dinge festhalten: AC oder Akku, den power mode und den aktiven power plan.

Ist es ein Defekt, wenn der power plan „High performance“ nicht angezeigt wird?

Wahrscheinlich kein Defekt. Microsofts Dokumentation zufolge sind bei Modern-Standby-fähigen Geräten nur Balanced oder von Balanced abgeleitete Pläne zulässig. Es ist also durchaus normal, dass High performance bei diesem Gerätetyp konstruktionsbedingt nicht auftaucht. Lässt sich außerdem die power-mode-Oberfläche nicht ändern, könnte ein custom power plan ausgewählt sein — dann lohnt es sich zuerst, Balanced auszuwählen.

In welcher Reihenfolge sollte man den Geschwindigkeitsvergleich zwischen Version A und B ausführen?

Man sollte vermeiden, A zuerst komplett durchlaufen zu lassen und dann B, weil sich Verzerrungen durch Wärme, Cache und Hintergrundaktivität dann einseitig auf eine Version legen. Führen Sie stattdessen abwechselnd A B A B aus oder nutzen Sie eine vorab erzeugte Zufallsreihenfolge. Messen Sie außerdem den kalten ersten Durchlauf getrennt vom eingeschwungenen Zustand nach dem Aufwärmen, und betrachten Sie neben dem Mittelwert auch Median, p95, Minimum und Maximum, damit Ausreißer das Ergebnis nicht verzerren.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.