CPU-Einstellungen für Windows-App-Entwickler: Priorität, Affinität und P-Kerne/E-Kerne

Die Leistung einer Windows-App wird nicht allein durch den Code bestimmt. Dieselbe .exe kann sich je nach PC, auf dem sie läuft, unterschiedlich anfühlen.

Auf einem PC läuft die periodische Verarbeitung stabil.
Auf einem anderen hakt sie gelegentlich.
Am Netzteil gibt es keine Probleme, im Akkubetrieb ist sie seltsam langsam.
Sie haben im Task-Manager die Priorität erhöht, aber es wurde nicht so viel schneller wie erwartet.
Sie dachten, Sie hätten die Verarbeitung auf die P-Kerne gelenkt, aber die Verarbeitungszeit schwankt weiterhin.
Und umgekehrt: Wenn Sie versuchen, die Leistung zu steigern, läuft der Lüfter durchgehend, und andere Apps werden träge.

Wer Windows-Apps entwickelt, stößt auf genau solche Phänomene, die sich allein aus dem Code kaum erklären lassen.

In diesem Moment lohnt sich der Blick auf diese vier Dinge.

Auf modernen Windows-Systemen kommen dazu noch EcoQoS und der Efficiency mode des Task-Managers hinzu.

Die Ausführungsumgebung einer Windows-App ist also nicht einfach nur die Frage, „ob die CPU schnell oder langsam ist“.

Wann wird sie ausgeführt
Wo wird sie ausgeführt
Auf welcher Art von Kern wird sie ausgeführt
In welchem Leistungszustand läuft die CPU dabei
Hält das Betriebssystem sie für „leistungskritisch“ oder für „ausreichend im Energiesparmodus“

Erst das Zusammenspiel all dessen bestimmt die tatsächliche Reaktionsfähigkeit und Verarbeitungszeit.

Dieser Artikel ordnet den Zusammenhang zwischen Priorität, Affinität, P-Kernen/E-Kernen und Energiespareinstellungen – Dinge, die bei der Windows-App-Entwicklung leicht übersehen werden.

Der Code aus diesem Artikel ist als buildbares, lauffähiges Beispielpaket auf GitHub veröffentlicht (eine C#-Bibliothek samt Demo für Priorität und Affinität, PowerShell-Skripte und Unit-Tests).

windows-app-cpu-priority-affinity-power - komurasoft-blog-samples (GitHub)

1. Zunächst das Gesamtbild

Zunächst das Gesamtbild als Diagramm.

flowchart LR
  A["Anwendungscode"] --> B["Windows-Scheduler"]

  P["Priorität<br/>wie leicht sie ausgeführt wird"] --> B
  AF["Affinität / CPU Sets<br/>auf welchen CPUs sie laufen darf"] --> B
  Q["QoS / EcoQoS<br/>leistungsorientiert oder energieeffizient"] --> B

  B --> C["Auszuführenden Thread auswählen"]
  C --> D["Auszuführenden logischen Prozessor auswählen"]

  PE["P-Kern / E-Kern<br/>leistungs- oder effizienzorientiert"] --> D
  PM["Energiemodus / Energieplan / PPM<br/>Taktfrequenz, Boost, Core Parking"] --> D

  D --> R["Tatsächliche Reaktionsfähigkeit<br/>Verarbeitungszeit<br/>Wärmeentwicklung<br/>Akkuverbrauch<br/>Auswirkung auf andere Apps"]

Wichtig ist: All das ist nicht unabhängig voneinander.

Erhöhen Sie die Priorität, wird die Ausführung wahrscheinlicher.
Wird die CPU selbst aber in Richtung Energiesparen gesteuert, wird sie womöglich nicht so schnell wie erhofft.

Schränken Sie mit der Affinität die CPUs ein, sinkt womöglich die Anzahl der Thread-Wechsel.
Landet die Einschränkung aber auf effizienzorientierten Kernen oder passt sie nicht zu Core Parking und Energieverwaltung, kann sich das ins Gegenteil verkehren.

Lenken Sie die Verarbeitung auf die P-Kerne, wird die Berechnung womöglich schneller.
Schieben Sie aber alles auf die Hochleistungsseite, steigen Wärmeentwicklung, Lüftergeräusch, Akkuverbrauch und die Auswirkung auf andere Prozesse.

Leistungsoptimierung bei Windows-Apps ist nicht die einfache Suche nach einem „Schneller“-Knopf.

Welche Verarbeitung soll schnell sein?
Welche darf langsam sein?
Hat die Reaktionsfähigkeit auf Benutzereingaben Vorrang?
Hat die Abschlusszeit von Hintergrundverarbeitung Vorrang?
Wie viel Akkuverbrauch und Wärme sind akzeptabel?

Genau das ist die eigentliche Designfrage.

2. Priorität bedeutet: „Wie leicht wird sie ausgeführt“

Gibt es unter Windows mehrere lauffähige Threads, entscheidet der Scheduler, „welcher Thread als Nächstes auf die CPU kommt“. Genau hier wirkt die Priorität.

Grob gesehen wird die Priorität in zwei Stufen bestimmt.

Prozess-Prioritätsklasse
  + relative Thread-Priorität
  = Basispriorität des Threads

In der Win32-API gibt es auf Prozessseite SetPriorityClass und auf Thread-Seite SetThreadPriority.

Um die Priorität eines gerade laufenden Prozesses in PowerShell anzuzeigen, geht das zum Beispiel so.

Get-Process -Id $PID | Select-Object Id, ProcessName, PriorityClass

Um die Priorität des aktuellen PowerShell-Prozesses zu erhöhen, so.

$p = Get-Process -Id $PID
$p.PriorityClass = "AboveNormal"

In C# lässt sich das so schreiben.

using System.Diagnostics;

using var process = Process.GetCurrentProcess();
process.PriorityClass = ProcessPriorityClass.AboveNormal;

Wichtig ist hier: Priorität ist keine Einstellung, die „die CPU schneller macht“. Sie betrifft nur, welcher Thread bei Konkurrenz zuerst läuft.

Sie ist keine Einstellung, die die CPU-Taktfrequenz erhöht.
Sie ist auch keine Einstellung, die P-Kerne auswählt.
Sie beschleunigt auch keine I/O.
Und sie beseitigt auch keine Lock- oder Netzwerkwartezeiten.

Deshalb kommt es ganz normal vor, dass „die Priorität erhöht wurde, es aber nicht schneller wird“. Liegt die Ursache der Langsamkeit zum Beispiel an Folgendem, löst eine höhere Priorität das Problem nicht wirklich:

• Warten auf Festplatten-I/O
• Warten auf das Netzwerk
• Warten auf eine DB-Antwort
• Lock-Konkurrenz
• GC-Pausen
• Ein blockierter UI-Thread
• Warten auf GPU oder Treiberseite
• Dateiscans durch Antivirensoftware
• Die CPU-Taktfrequenz wird zugunsten des Energiesparens gedrosselt

Auch HIGH_PRIORITY_CLASS und REALTIME_PRIORITY_CLASS sollten nicht leichtfertig verwendet werden.

Ein Thread, der lange Zeit mit hoher Priorität läuft, gibt CPU-Zeit an andere Threads nur ungern ab.
Bliebe das auf die eigene App beschränkt, wäre es noch zu verschmerzen – es kann aber die Reaktionsfähigkeit des gesamten Systems verschlechtern.

Priorität ist wie ein Medikament.

In den Situationen, in denen sie wirkt, wirkt sie.
Aber mehr davon ist nicht automatisch besser.

Was Sie vor einer Prioritätserhöhung bedenken sollten

Bevor Sie die Priorität erhöhen, lohnt sich zunächst ein Blick auf Folgendes.

Bei einer Windows-App kommt es nicht darauf an, ständig mit höchster Priorität zu laufen, sondern die nötige Verarbeitung zur nötigen Zeit und nur im nötigen Umfang zu bevorzugen.

3. Affinität bedeutet: „Auf welcher CPU darf sie laufen“

Ist Priorität „wie leicht sie ausgeführt wird“, dann ist Affinität „auf welcher CPU sie laufen darf“.

Unter Windows lässt sich für Prozesse und Threads die Menge der logischen Prozessoren festlegen, auf denen sie ausgeführt werden dürfen.

In der Win32-API gibt es dafür SetProcessAffinityMask für Prozesse und SetThreadAffinityMask für Threads.

Um die Affinität eines Prozesses in PowerShell anzuzeigen, geht das zum Beispiel so.

Get-Process -Id $PID | Select-Object Id, ProcessName, ProcessorAffinity

Um zu Testzwecken den aktuellen PowerShell-Prozess auf die ersten vier logischen Prozessoren einzuschränken, lässt sich das so schreiben.

$p = Get-Process -Id $PID
$p.ProcessorAffinity = [IntPtr]0xF

0xF ist binär 1111.
Das heißt, die logischen Prozessoren 0 bis 3 sind erlaubt.

Das ist allerdings nur ein Beispiel zu Testzwecken.

Eine engere Affinität kann die Lokalität des CPU-Caches verbessern und die Schwankung periodischer Verarbeitung verringern.
Andererseits sperrt sie Threads, die Windows eigentlich auf eine freie CPU hätte verschieben können, in einen engen Raum ein.

Besonders in folgenden Umgebungen ist Vorsicht geboten.

• P-Kerne und E-Kerne sind gemischt vorhanden
• Bei SMT/Hyper-Threading (Simultaneous Multi-Threading – ein Mechanismus, der einen physischen Kern als mehrere logische Prozessoren erscheinen lässt) ist die Zuordnung zwischen logischen Prozessoren und physischen Kernen nicht intuitiv
• Es liegt eine NUMA-Konfiguration vor (Non-Uniform Memory Access – eine Anordnung, bei der der Abstand zum Speicher aus Sicht der CPU nicht einheitlich ist)
• Mehr als 64 logische Prozessoren, sodass Processor Groups eine Rolle spielen
• Core Parking ist aktiviert
• Die Energieverwaltung von OEM oder BIOS greift stark ein
• Sie läuft in einer virtualisierten Umgebung

Affinität ist eine Einstellung, die dem System recht stark vorschreibt: „Lauf nur auf diesen CPUs“.

Einschränkungen können ein Werkzeug zur Stabilisierung sein.
Falsch eingesetzt, verbauen sie aber Ausweichmöglichkeiten.

Heute gibt es auch CPU Sets

Die klassische Affinitätsmaske ist eine ziemlich starke Einschränkung.

Windows verfügt daneben aber auch über einen Mechanismus namens CPU Sets.
CPU Sets ist eine API, mit der die Anwendung ihre CPU-Präferenzen weicher formulieren kann.

Laut Microsofts Beschreibung sind CPU Sets als „weiche“ Affinitätsangabe positioniert, die mit der Energieverwaltung des Betriebssystems kompatibel ist.

Wollen Sie die CPU strikt festlegen?
Oder wollen Sie den Ausführungsort nur grob steuern, während Sie mit der Energieverwaltung und Planung des Betriebssystems kooperieren?

Dieser Unterschied ist wichtig.

Statt zu versuchen, alles mit dem altehrwürdigen SetProcessAffinityMask zu lösen, müssen moderne Windows-Apps auch CPU Sets und QoS mit einbeziehen.

4. P-Kerne/E-Kerne: „Auch CPUs haben einen Charakter“

Bei aktuellen CPUs haben nicht mehr alle Kerne dieselbe Leistung und denselben Stromverbrauch. Das bekannteste Beispiel sind P-Kerne und E-Kerne: Grob gesagt sind P-Kerne leistungsorientiert und E-Kerne effizienzorientiert.

Es ist allerdings riskant, wenn Entwickler leichtfertig festlegen: „CPU 0–7 sind P-Kerne, 8–15 sind E-Kerne“. Die Reihenfolge der CPU-Nummern kann je nach CPU, BIOS, Windows-Version, Firmware, OEM-Einstellungen und Virtualisierungsumgebung variieren.

Auf Windows-Seite gibt es in den CPU-Sets-Informationen das Konzept EfficiencyClass.
Das ist ein Wert, der auf Systemen mit heterogenen Prozessoren die Effizienzcharakteristik dieses CPU Sets angibt. Microsofts Dokumentation erklärt, dass ein CPU Set mit einem höheren Wert einen schnelleren, aber weniger energieeffizienten Prozessor besitzt.

Wer P-Kerne/E-Kerne gezielt nutzen will, kommt mit einem bloßen Blick auf die CPU-Nummer nicht weit. Wer es wirklich genau wissen will, braucht Beobachtungen wie diese.

• Mit der CPU-Sets-API EfficiencyClass abfragen
• Mit Windows Performance Recorder / Analyzer (WPR / WPA – das Standardwerkzeug zum Erfassen und Auswerten von ETW-Traces) die ausführende CPU jedes Threads beobachten
• Über die Anzeige der logischen Prozessoren im Task-Manager Tendenzen erkennen
• Verarbeitungszeiten auf jedem einzelnen Gerät messen
• Netzbetrieb und Akkubetrieb vergleichen
• Verschiedene Energiemodi vergleichen

P-Kerne/E-Kerne sind nicht bloß eine Hardwarespezifikation – erst im Zusammenspiel mit dem Windows-Scheduler, QoS und den Energiespareinstellungen entscheidet sich, wo tatsächlich ausgeführt wird.

5. Energiespareinstellungen bestimmen, „wie ernsthaft die CPU hochdreht“

Das ist in der Praxis ziemlich wichtig.

Priorität ist „welcher Thread zuerst läuft“.
Affinität ist „auf welcher CPU er laufen darf“.
P-Kerne/E-Kerne sind „ob diese CPU leistungs- oder effizienzorientiert ist“.

Und die Energiespareinstellungen betreffen,

mit welcher Taktfrequenz und welchem Energiezustand die CPU überhaupt läuft.

Das heißt, Folgendes kann passieren:

Sie haben die Priorität erhöht.
Sie haben auf die P-Kerne gelenkt.
Sind die Energieeinstellungen aber auf Sparen ausgerichtet,
dreht die CPU vielleicht trotzdem nicht ernsthaft auf.

Das ist eine ziemlich typische Windows-Geschichte.

Unter Windows 11 lässt sich der Energiemodus in der Einstellungen-App unter „System > Netzbetrieb & Akku“ wählen.
Die Beschriftung variiert je nach Umgebung und Version, aber die Ausrichtung ist ungefähr diese.

Daneben gibt es weiterhin die klassischen Energiepläne Power Saver, Balanced und High Performance.
Balanced passt Leistung und Energieverbrauch je nach Bedarf an, High Performance ist eine Einstellung, die zulasten des Energieverbrauchs leichter die maximale Leistung erreicht.

So einfach die für den Benutzer sichtbaren Einstellungen auch sind – dahinter stecken die Einstellungen des Processor Power Management (PPM).

6. P-State, C-State, Boost und EPP

Eine CPU läuft nicht ständig mit maximaler Taktfrequenz, sondern verfügt über Zustände, um den Stromverbrauch zu senken.

P-States sind der Mechanismus, mit dem die CPU durch Ändern von Taktfrequenz und Spannung den Stromverbrauch senkt.
C-States sind der Mechanismus, mit dem die CPU im Leerlauf einen Teil ihrer Funktionen abschaltet und in einen tieferen Energiesparzustand wechselt.

Die Energieverwaltung von Windows nutzt diese Mechanismen, um Leistung und Stromverbrauch auszubalancieren.

Deshalb ist das Phänomen „hohe Priorität, aber trotzdem langsam“ durchaus möglich.

Der Thread wird bevorzugt ausgeführt.
Aber die CPU-Taktfrequenz ist niedrig.
Boost wird kaum erreicht.
EPP ist auf Energiesparen ausgerichtet.
Core Parking schränkt die verfügbaren Kerne ein.
Im Akkubetrieb agiert das gesamte Betriebssystem auf Energiesparen ausgerichtet.

In solchen Fällen kommen Sie der Ursache nicht auf die Spur, wenn Sie nur die Priorität betrachten.

Besonders bei periodischer Verarbeitung, Bildverarbeitung, Messgerätesteuerung, Videoverarbeitung, Audioverarbeitung, USB-Kamera-Erfassung und serieller Kommunikation ist nicht nur die durchschnittliche Verarbeitungszeit das Problem, sondern das „gelegentliche Verzögern“.

Im Schnitt ist es schnell.
Aber einmal von tausend Malen hakt es.
Dieses eine Mal verstopft den Puffer.
Die UI friert ein.
Das Timing mit dem Gerät gerät durcheinander.

Bei solchen Phänomenen reicht der Durchschnitt der CPU-Auslastung allein nicht aus.

Sie müssen die Verteilung der Verarbeitungszeiten, den Maximalwert, Ausreißer, den Energiezustand, die ausführende CPU und die Hintergrundlast gemeinsam betrachten.

7. Core Parking bestimmt „die Anzahl der nutzbaren Kerne“

Windows verfügt über einen Mechanismus namens Core Parking. Er sorgt dafür, dass ungenutzte logische Prozessoren ruhen.
Bei niedriger Auslastung werden einige Kerne in einen Zustand niedrigen Energieverbrauchs versetzt, um den Stromverbrauch zu senken.

Microsofts Dokumentation beschreibt CPMinCores als die Einstellung, die angibt, wie viel Prozent der logischen Prozessoren zu einem beliebigen Zeitpunkt mindestens un-parked, also nutzbar, bleiben müssen.
Setzen Sie den Wert auf 100 %, wird der Core-Parking-Algorithmus deaktiviert.

Zum Problem wird hier die Kombination mit der Affinität.

Sie haben per Affinität eingeschränkt: „Bitte auf dieser CPU-Gruppe laufen.“
Wie die Energieverwaltung diese Kerne behandelt, ist aber eine andere Frage.

Auch die Dokumentation für Windows Server erklärt, dass es Situationen geben kann, in denen dies nicht mit den Entscheidungen von Core Parking zusammenpasst, wenn aktive Threads stark auf einen Teil der CPUs innerhalb eines NUMA-Knotens affinisiert sind.

Als Denkweise ist das auch für Client-PCs hilfreich.

Affinität schränkt den Scheduler ein.
Core Parking betrifft, „welche Kerne die Energieverwaltung nutzbar hält“.

Betrachten Sie diese beiden Dinge getrennt voneinander, verkennen Sie die Ursache.

8. EcoQoS / Efficiency Mode: der Mechanismus, um mitzuteilen, „diese Arbeit darf energiesparend laufen“

Früher drehte sich die Leistungsoptimierung von Windows-Apps hauptsächlich darum, die Priorität zu erhöhen oder zu senken und die Affinität zu ändern. Modernes Windows kennt aber noch ein etwas anderes Konzept: QoS.

QoS – Quality of Service – ist das Konzept, pro Thread anzugeben, „wie stark diese Arbeit auf Leistung beziehungsweise auf Energiesparen ausgerichtet sein soll“.

Microsofts Dokumentation erklärt, dass die Scheduling-Priorität weiterhin der maßgebliche Faktor dafür bleibt, welcher Thread als Nächstes ausgeführt wird, während QoS die Kernauswahl und die Prozessorenergieverwaltung beeinflussen kann.

Insbesondere EcoQoS ist der Mechanismus, um Arbeit, bei der Leistung nicht oberste Priorität hat, energiesparender zu behandeln.

In C++ lässt sich der aktuelle Thread beispielsweise mit SetThreadInformation und ThreadPowerThrottling auf EcoQoS setzen.

#include <windows.h>

void EnableEcoQoSForCurrentThread()
{
    THREAD_POWER_THROTTLING_STATE powerThrottling = {};
    powerThrottling.Version = THREAD_POWER_THROTTLING_CURRENT_VERSION;
    powerThrottling.ControlMask = THREAD_POWER_THROTTLING_EXECUTION_SPEED;
    powerThrottling.StateMask = THREAD_POWER_THROTTLING_EXECUTION_SPEED;

    SetThreadInformation(
        GetCurrentThread(),
        ThreadPowerThrottling,
        &powerThrottling,
        sizeof(powerThrottling));
}

Um umgekehrt wieder zu leistungsorientiertem Verhalten zurückzukehren, setzen Sie für dasselbe Steuerungsziel StateMask auf 0.

void DisableEcoQoSForCurrentThread()
{
    THREAD_POWER_THROTTLING_STATE powerThrottling = {};
    powerThrottling.Version = THREAD_POWER_THROTTLING_CURRENT_VERSION;
    powerThrottling.ControlMask = THREAD_POWER_THROTTLING_EXECUTION_SPEED;
    powerThrottling.StateMask = 0;

    SetThreadInformation(
        GetCurrentThread(),
        ThreadPowerThrottling,
        &powerThrottling,
        sizeof(powerThrottling));
}

Wollen Sie das aus C# heraus nutzen: Die .NET-Klassenbibliothek besitzt keinen eigenen Typ zum Setzen von EcoQoS. Sie rufen SetThreadInformation per P/Invoke auf. Es folgt eine Schreibweise, die von .NET 8 ausgeht.

using System;
using System.ComponentModel;
using System.Runtime.InteropServices;

internal static class EcoQos
{
    // ThreadPowerThrottling aus THREAD_INFORMATION_CLASS
    private const int ThreadPowerThrottling = 3;

    // THREAD_POWER_THROTTLING_CURRENT_VERSION
    private const uint CurrentVersion = 1;

    // THREAD_POWER_THROTTLING_EXECUTION_SPEED
    private const uint ExecutionSpeed = 0x1;

    [StructLayout(LayoutKind.Sequential)]
    private struct ThreadPowerThrottlingState
    {
        public uint Version;
        public uint ControlMask;
        public uint StateMask;
    }

    [DllImport("kernel32.dll", SetLastError = true)]
    private static extern IntPtr GetCurrentThread();

    [DllImport("kernel32.dll", SetLastError = true)]
    [return: MarshalAs(UnmanagedType.Bool)]
    private static extern bool SetThreadInformation(
        IntPtr hThread,
        int threadInformationClass,
        ref ThreadPowerThrottlingState threadInformation,
        uint threadInformationSize);

    /// <summary>Versetzt den aktuellen Thread in EcoQoS (mit false zurück zu leistungsorientiert).</summary>
    public static void SetForCurrentThread(bool enabled)
    {
        var state = new ThreadPowerThrottlingState
        {
            Version = CurrentVersion,
            ControlMask = ExecutionSpeed,
            StateMask = enabled ? ExecutionSpeed : 0u,
        };

        var ok = SetThreadInformation(
            GetCurrentThread(),
            ThreadPowerThrottling,
            ref state,
            (uint)Marshal.SizeOf<ThreadPowerThrottlingState>());

        if (!ok)
        {
            throw new Win32Exception(Marshal.GetLastWin32Error());
        }
    }
}

Der Aufruf sieht dann so aus. Da EcoQoS eine Einstellung pro Thread ist, ist es sicherer, einen eigenen Thread zu starten und das Setzen und Zurücksetzen darin vorzunehmen.

using System.Threading;

// RunBackgroundMaintenance ist die "nicht eilige Arbeit", die Sie selbst bereitstellen
var worker = new Thread(() =>
{
    EcoQos.SetForCurrentThread(true);
    try
    {
        RunBackgroundMaintenance();
    }
    finally
    {
        // Nach der Nutzung unbedingt zurücksetzen
        EcoQos.SetForCurrentThread(false);
    }
})
{
    IsBackground = true,
};

worker.Start();

Wichtig ist hier: Setzen Sie es nicht direkt auf Task.Run oder Threads des Thread-Pools. Das Ziel der Einstellung ist der OS-Thread, nicht der laufende Task. Setzen Sie EcoQoS auf einen Pool-Thread, bleibt dieser auch dann energiesparend eingestellt, wenn er als Nächstes für eine andere Aufgabe eingesetzt wird. Wechselt bei async/await die Fortsetzung auf einen anderen Thread, wirkt die Einstellung mal innerhalb, mal außerhalb des beabsichtigten Bereichs.

EcoQoS ist keine Funktion, bei der einfach alles auf Energiesparen gestellt werden sollte. Geeignet ist sie zum Beispiel für Arbeit wie diese.

• Hintergrundsynchronisation
• Indexerstellung mit niedriger Priorität
• Nicht eilige Log-Aggregation
• Cache-Aktualisierungen ohne direkten Bezug zu Benutzeraktionen
• Wartungsarbeiten, die auch später fertig werden dürfen

Bei folgender Arbeit sollten Sie dagegen vorsichtig sein.

• Arbeit, die direkt mit UI-Interaktionen zusammenhängt
• Kameraerfassung
• Audioverarbeitung
• Arbeit, die mit einem Regelzyklus zusammenhängt
• Beurteilungslogik von Prüfgeräten
• Exportvorgänge, auf die der Benutzer wartet
• Verarbeitung, die eine nahezu echtzeitfähige Antwort benötigt

Auch der Efficiency mode des Task-Managers hängt mit diesem Konzept zusammen.
Microsofts Performance-Diagnostics-Blog erklärt, dass das Aktivieren des Efficiency mode die Basispriorität des Prozesses auf Low senkt und dessen QoS auf EcoQoS setzt.

Efficiency mode ist also nicht bloß ein „Energiespar-Symbol“, sondern ein Mechanismus, der Prioritätsabsenkung und EcoQoS kombiniert, um die Reaktionsfähigkeit von Vordergrund-Apps und die Energieeffizienz zu schützen.

Aus Entwicklersicht ist das ziemlich wichtig.

Denn Sie können ein Design entwerfen, das dem Betriebssystem nicht nur mitteilt: „Diese Arbeit soll schnell fertig werden“, sondern auch:
„Diese Arbeit muss nur laufen, ohne den Benutzer zu stören“.

9. Entscheidungs-Flussdiagramm

Weil das bisher Beschriebene komplex ist, hier ein Entscheidungsablauf für die Untersuchung von Leistung und Zyklusschwankungen bei Windows-Apps.

flowchart TD
  A["Symptom<br/>langsam / Zyklus schwankt / UI friert ein / lauter Lüfter"] --> B["Zuerst aufzeichnen<br/>Verarbeitungszeit / Maximum / CPU-Auslastung / Energiezustand / Netz oder Akku / betroffener PC"]
  B --> C{"Ist die CPU die Hauptursache?"}

  C -- "Nein / unklar" --> D["I/O, Locks, DB, Netzwerk, GC, GPU, Treiber prüfen<br/>Wartezeiten beseitigen, bevor Sie Priorität oder Affinität anfassen"]
  C -- "Ja" --> E{"Starke CPU-Konkurrenz mit anderen Prozessen?"}

  E -- "Ja" --> F["Priorität in Betracht ziehen<br/>aber den Bereich begrenzen<br/>Dauerhafte Nutzung von High/Realtime vermeiden"]
  E -- "Nein" --> G{"Ausführung auf bestimmte CPUs konzentriert?"}

  G -- "Ja" --> H["Affinität / CPU Sets prüfen<br/>zu stark fixiert?<br/>P-/E-Kerne und NUMA berücksichtigt?"]
  G -- "Nein" --> I{"Taktfrequenz oder Energiezustand verdächtig?"}

  I -- "Ja" --> J["Energiemodus / Energieplan / PPM prüfen<br/>P-State / EPP / Boost / Core Parking verdächtigen"]
  I -- "Nein" --> K{"Stört Hintergrundarbeit den Vordergrund?"}

  K -- "Ja" --> L["EcoQoS / Efficiency Mode / Prioritätsabsenkung in Betracht ziehen<br/>Nicht eilige Arbeit zur energiesparenden Seite verschieben"]
  K -- "Nein" --> M["Algorithmus, Parallelitätsgrad, Warteschlangen-Design und UI-Thread-Design überdenken"]

  F --> N["Jeweils einen Punkt ändern und per A/B messen"]
  H --> N
  J --> N
  L --> N
  M --> N

  N --> O["Nicht nur den Durchschnitt, sondern auch<br/>Maximum, Ausreißer, Wärmeentwicklung und Auswirkung auf andere Apps betrachten"]

Wichtig an diesem Ablauf ist, nicht von Anfang an an Einstellungen zu drehen. Zuerst wird aufgezeichnet.

• Ist es dauerhaft langsam?
• Oder nur gelegentlich?
• Netzbetrieb oder Akku?
• Welcher Energiemodus ist aktiv?
• Steht der Prozess im Task-Manager auf Efficiency mode?
• Ist die CPU-Auslastung hoch?
• Steigt die Taktfrequenz?
• Welcher Thread nutzt die CPU?
• Wie hoch ist die maximale Verarbeitungszeit?
• Spielt andere residente Software oder Antivirensoftware eine Rolle?

Auf dieser Basis ändern Sie dann jeweils einen Punkt.

Priorität ändern.
Affinität ändern.
Energiemodus ändern.
EcoQoS setzen.
Hintergrundverarbeitung abtrennen.
Eine Warteschlange einführen.
Vom UI-Thread entfernen.

Ändern Sie mehrere Dinge gleichzeitig, wissen Sie hinterher nicht mehr, was gewirkt hat.

10. Befehle zur Überprüfung in der Praxis

Verhält sich eine Windows-App je nach Umgebung unterschiedlich, ist es hilfreich, zunächst den Zustand erfassen zu können.

CPU-Informationen anzeigen

Get-CimInstance Win32_Processor |
  Select-Object Name, NumberOfCores, NumberOfLogicalProcessors, MaxClockSpeed

Den aktiven Energieplan anzeigen

powercfg /getactivescheme

Die Einstellungen der Prozessorenergieverwaltung anzeigen

powercfg /q SCHEME_CURRENT SUB_PROCESSOR

Die Ausgabe ist recht lang, doch Sie können die Einstellungen zu minimalem und maximalem Prozessorzustand, EPP, Boost und Core Parking prüfen.
Welche Einträge sichtbar sind, hängt von der Umgebung ab.

Einen Energieeffizienz-Diagnosebericht erstellen

Führen Sie den Befehl in einem Terminal mit Administratorrechten aus.

powercfg /energy

Nach einer festgelegten Messdauer wird ein HTML-Bericht ausgegeben.
Er ist ein Einstiegspunkt, um Treiber, Geräte, Timer-Auflösung, USB-Energiesparen, Schlafverhinderer und Ähnliches zu betrachten.

Priorität und Affinität eines Zielprozesses anzeigen

Get-Process -Name MyApp |
  Select-Object Id, ProcessName, PriorityClass, ProcessorAffinity

Im Task-Manager prüfen

Auf Kundengeräten lässt sich PowerShell manchmal nicht öffnen. Wollen Sie nur über die GUI prüfen, schauen Sie an folgenden Stellen. Da sich die Beschriftung je nach Windows-Version unterscheidet, ist der englische Name in Klammern mit angegeben.

Der Effizienzmodus lässt sich nicht auf Kernprozesse von Windows anwenden, da deren Drosselung die Systemstabilität gefährden würde.

Der Effizienzmodus ist zudem kein bloßes Anzeige-Label. Microsofts Performance-Diagnostics-Blog erklärt, dass der Effizienzmodus die Basispriorität des Prozesses auf Low senkt und dessen QoS auf EcoQoS setzt. Er wendet also lediglich die beiden in Kapitel 8 beschriebenen Einstellungen gebündelt über die GUI an.

Was auf der Seite „Details“ des Task-Managers zu sehen ist, ist im Übrigen ausschließlich die Priorität auf Prozessebene. Die relative Priorität einzelner Threads oder das QoS pro Thread werden nicht angezeigt. Wollen Sie so tief blicken, erfassen Sie ETW mit WPR/WPA.

Den Leistungszustand der CPU anzeigen

Welche Zählernamen verfügbar sind, variiert je nach Umgebung, aber diese Performance Counter sind ein guter Anhaltspunkt.

Get-Counter '\Processor Information(_Total)\% Processor Performance'

Get-Counter '\Processor Information(_Total)\% Processor Utility'

Für eine ernsthafte Untersuchung ist es zuverlässiger, mit Windows Performance Recorder (WPR) und Windows Performance Analyzer (WPA) ETW zu erfassen.
So lassen sich Zyklusschwankungen, Kontextwechsel, die ausführende CPU, DPC/ISR (Deferred Procedure Call / Interrupt Service Routine – die Interrupt-Behandlung von Treibern und deren aufgeschobene Ausführung), Festplatten-I/O und Änderungen der CPU-Taktfrequenz gemeinsam verfolgen.

11. Bei Soft-Realtime-Verarbeitung müssen Sie alles zusammen betrachten

Windows ist im üblichen Sinne kein Echtzeit-Betriebssystem. In der Praxis wird von Windows-Apps aber mitunter ein nahezu echtzeitfähiges Verhalten verlangt.

• In festen Zyklen Bilder von einer USB-Kamera erfassen
• Über serielle Kommunikation mit einem Gerät kommunizieren
• Daten von Messgeräten einlesen
• Mit einer SPS oder externen Geräten synchronisieren
• Audio oder Video verarbeiten
• Prüfergebnisse innerhalb einer festen Zeit zurückgeben
• Schwere Berechnungen ausführen, ohne die UI einfrieren zu lassen

Bei solcher Arbeit reicht schneller Code allein nicht aus.

Sie brauchen ein Thread-Design.
Sie brauchen ein Warteschlangen-Design.
Sie brauchen Logging.
Sie brauchen Timeouts.
Sie brauchen Backpressure (einen Mechanismus, der die vorgelagerte Durchflussrate gezielt drosselt, wenn die nachgelagerte Seite nicht mehr mithält).
Sie müssen festlegen, ob bei Verzögerung verworfen, gewartet oder erneut versucht wird.

Und darauf aufbauend müssen Sie Priorität, Affinität, P-Kerne/E-Kerne und Energiespareinstellungen betrachten.

Betrachten wir zum Beispiel einen Kamera-Erfassungs-Thread.

Dieser Thread steht nahe an der Benutzerinteraktion und hat auch Periodizität.
Deshalb sollte ihm kein EcoQoS zugewiesen werden.
Die Priorität lohnt sich, nur für den Erfassungsabschnitt um eine Stufe anzuheben. Dauerhaft HIGH_PRIORITY_CLASS oder höher zu verwenden, sollten Sie aber vermeiden – das wirkt sich negativ auf die UI und andere Verarbeitung aus.
Die Affinität fixieren Sie nur, wenn Messungen tatsächlich eine Korrelation zwischen Zyklusschwankung und CPU-Wechsel zeigen. Fixieren Sie sie, sollten Sie nicht anhand der CPU-Nummer, sondern anhand von EfficiencyClass die P-Kern-Seite wählen. Eine Fixierung auf E-Kerne würde den gegenteiligen Effekt haben.
Neigt der Energiemodus zum Energiesparen, treten im Akkubetrieb Verzögerungen auf, die im Netzbetrieb nicht auftraten. Nehmen Sie deshalb den Akkubetrieb unbedingt in Ihre Leistungstests auf.

Wie sieht es dagegen bei der Komprimierung alter Logs aus?

Das ist ein typisches Beispiel für Arbeit, auf die kein Benutzer wartet.
Dann senken Sie die Priorität.
Setzen Sie EcoQoS.
Lassen Sie sie im Leerlauf laufen.
Lassen Sie sie nur im Netzbetrieb laufen.
Ein solches Design ist für die App als Ganzes freundlicher.

Statt alle Vorgänge „schnell“ zu machen, trennen Sie Arbeit, die schnell sein soll, von Arbeit, die nicht stören soll.

12. Grundlegende Designprinzipien

Für den Umgang damit gibt es bei Windows-Apps sechs grundlegende Prinzipien.

1. Nicht von Anfang an fixieren

Es ist besser, Priorität und Affinität nicht von Anfang an stark zu fixieren.

Der Windows-Scheduler macht seine Sache in den meisten Fällen ziemlich gut.
Legt die App zusätzliche, unnötige Einschränkungen auf, kann sich die Situation dadurch sogar verschlechtern.

Zuerst ganz normal bauen.
Messen.
Tritt ein Problem auf, eine Hypothese aufstellen.
Klein ändern.
Erneut messen.

In dieser Reihenfolge.

2. Priorität nur vorübergehend nutzen

Beschränken Sie hohe Priorität auf den Abschnitt, in dem sie nötig ist.

Statt sie dauerhaft hoch zu halten, ist es sicherer,

kurz vor der wichtigen Arbeit zu erhöhen
und nach Abschluss zurückzusetzen.

3. Affinität erst gegen Ende in Betracht ziehen

Affinität ist eine starke Einstellung.

Wird ein Zusammenhang zwischen Zyklusschwankungen und CPU-Wechseln vermutet, kann sie wirksam sein.
Sie ist aber nicht die Einstellung, an die Sie zuerst Hand anlegen sollten.

Besonders wenn Kunden mehrere Arten von PCs einsetzen, ist ein Festlegen anhand fester CPU-Nummern riskant.

4. P-Kerne/E-Kerne nicht „festlegen“, sondern „beobachten“

Wollen Sie P-Kerne und E-Kerne gezielt einsetzen, beobachten Sie zunächst am realen Gerät.

Legen Sie sich nicht anhand der CPU-Nummer fest, sondern schauen Sie über CPU Sets, EfficiencyClass, ETW und tatsächliche Messungen.

5. Mit Energiespareinstellungen als Voraussetzung testen

Dass die Entwicklungsmaschine am Netz mit Höchstleistungseinstellung läuft und deshalb schnell ist, reicht allein nicht aus.

In Kundenumgebungen sind Zustände wie diese ganz normal.

• Laptops im Akkubetrieb
• Best power efficiency
• Energy saver
• OEM-eigene Energiespar-Dienstprogramme
• Durch Unternehmensrichtlinien fest vorgegebene Energieeinstellungen
• Dünne PCs, deren Leistung unter Wärme einbricht
• Geschäftsgeräte mit vielen residenten Programmen

In Leistungstests sollten Sie zumindest diese Bedingungen getrennt betrachten.

6. Für Hintergrundarbeit EcoQoS in Betracht ziehen

Bei Arbeit ohne direkten Bezug zur Benutzererfahrung kann es besser sein, dem Nicht-Stören Vorrang vor dem Streben nach Leistung zu geben.

Eine App, die alles mit Höchstleistung laufen lässt, ist vielleicht schnell.
Aber sie stört andere Arbeit.
Sie bringt den Lüfter des Laptops zum Laufen.
Sie verbraucht Akku.
Am Ende entsteht eine App, die unangenehm zu benutzen ist.

Bei Windows-Apps ist nicht nur Geschwindigkeit, sondern auch „gute Koexistenz“ ein Qualitätsmerkmal.

13. Verbreitete Missverständnisse

Höhere Priorität macht es schneller

Nicht zwangsläufig.

Ist CPU-Konkurrenz die Ursache, kann es wirken.
Liegt die Ursache aber an I/O-Wartezeiten, Lock-Wartezeiten, niedriger Taktfrequenz durch Energiesparen oder Ausführung auf E-Kernen, reicht Priorität allein nicht aus.

Fixierung auf P-Kerne ist immer richtig

Nicht immer richtig.

P-Kerne sind leistungsstark, aber auch Wärmeentwicklung und Stromverbrauch steigen.
Zudem können sie mit anderer wichtiger Vordergrundverarbeitung konkurrieren.

Wichtiger ist es, Arbeit, die auf P-Kerne gehört, von Arbeit zu trennen, für die E-Kerne ausreichen.

Energiespareinstellungen sind Geschmackssache des Benutzers und betreffen die App nicht

Sie betreffen die App sehr wohl.

Auch dieselbe App verhält sich je nach Energiemodus, Energieplan, EPP, Boost und Core Parking unterschiedlich.

Besonders bei Laptops ändert sich das Verhalten zwischen Netz- und Akkubetrieb.

Der Efficiency mode macht nur langsamer

Er macht nicht einfach nur langsamer.

Er ist ein Mechanismus, der durch Prioritätsabsenkung und EcoQoS die Reaktionsfähigkeit von Vordergrund-Apps und die Energieeffizienz schützt.
Für nicht eilige Hintergrundarbeit lohnt es sich, ihn aktiv in Betracht zu ziehen.

Es ist instabil, weil es Windows ist

Auch das ist eine oberflächliche Sichtweise.

Windows ist kein Echtzeit-Betriebssystem.
Verstehen Sie aber Scheduling, Energieverwaltung, QoS, Messung, Logging und Thread-Design, lässt sich die Stabilität für den Praxiseinsatz erheblich verbessern.

Das Problem ist nicht „geht nicht, weil es Windows ist“, sondern dass Sie nicht hinschauen, was auf welcher Ebene passiert.

14. Logging vor der Implementierung entwerfen

Probleme dieser Art treten manchmal nur in Kundenumgebungen auf. Deshalb hilft es, wenn die App zumindest minimale Diagnoseinformationen aufzeichnen kann.

Das Diagnoseprotokoll sollte zum Beispiel folgende Informationen ausgeben.

• App-Version
• Windows-Version
• CPU-Name
• Anzahl logischer Prozessoren
• Netzbetrieb oder Akku
• Durchschnitt, Maximum und Perzentile der Verarbeitungszeit
• Anzahl verzögerter Verarbeitungszyklen
• Priorität des Zielthreads
• Prozesspriorität
• Ob eine Affinität gesetzt ist
• Ob EcoQoS gesetzt ist
• Energieplan beim Start
• Anzahl der Timeouts der Zielverarbeitung

Heißt es beim Kunden „gelegentlich langsam“ und es gibt keinerlei Aufzeichnungen, wird es zum Ratespiel. Mit Logs lassen sich Hypothesen aufstellen.

Nur im Akkubetrieb langsam
Nur auf einem bestimmten PC langsam
Nur direkt nach dem Start langsam
Erst nach 30 Minuten langsam
Nur bei laufender anderer App langsam
Ausreißer treten in festem Zyklus auf

Werden solche Unterschiede sichtbar, lässt sich leichter eingrenzen, ob es an der Priorität, der Affinität, den Energieeinstellungen, der Wärme oder einer anderen Wartezeit liegt.

15. Die Sichtweise von KomuraSoft

Bei der Entwicklung von Windows-Apps reicht saubere Theorie allein nicht aus.

Auf dem PC des Kunden laufen.
Auf den Geräten vor Ort laufen.
Mit alten Peripheriegeräten koexistieren.
In Umgebungen mit Antivirensoftware, Druckern und Unternehmensrichtlinien funktionieren.
Auch unter den Energiespareinstellungen eines Laptops nicht zusammenbrechen.
Dort, wo Leistung gebraucht wird, tatsächlich Leistung liefern.
Bei nicht eiliger Arbeit den Benutzer nicht stören.

Dafür ist es besser, Windows nicht als bloße „Blackbox eines Betriebssystems“ zu betrachten.

Windows überlegt sich, wie es Threads laufen lässt.
Es überlegt sich, auf welcher CPU.
Es balanciert Energie und Leistung.
Es handhabt heterogene Kerne wie P-Kerne und E-Kerne.
Es versucht, Vordergrund-Apps von Hintergrundarbeit zu unterscheiden.

Entwickler sollten sich dem nicht widersetzen, sondern dort, wo es nötig ist, ihre Absicht mitteilen.

Diese Arbeit lässt den Benutzer warten.
Diese Arbeit darf etwas langsamer sein.
Bei dieser Arbeit ist der Zyklus entscheidend.
Diese Arbeit muss nur still im Hintergrund laufen.
Diese Arbeit darf andere Arbeit nicht stören.

Dieses Design übersetzen Sie in ein Verständnis von Priorität, Affinität, QoS und Energiespareinstellungen.

Weiterlesen

In diesem Artikel ging es um die Einstellungen auf der CPU-Seite. Liegt die Ursache für „langsam“ außerhalb der CPU, führen folgende Artikel schneller zum Ziel.

16. Fazit

Die Leistung einer Windows-App wird nicht allein durch den Code bestimmt.

Auch mit erhöhter Priorität verhält sie sich nicht wie erwartet, wenn die Affinität in Richtung E-Kerne zeigt.
Auch mit Ausrichtung auf P-Kerne liefert die CPU nicht die Maximalleistung, wenn der Energiemodus auf Sparen ausgerichtet ist.
Legen Sie eine starke Affinität fest, ohne CPU Sets und QoS zu berücksichtigen, verbauen Sie der Energieverwaltung und dem Scheduler von Windows die Ausweichmöglichkeiten.
Richten Sie alles auf die Hochleistungsseite aus, steigen Wärmeentwicklung, Lüftergeräusch, Akkuverbrauch und die Auswirkung auf andere Apps.

Bei der Windows-App-Entwicklung müssen Sie nicht nur Geschwindigkeit, sondern auch Reaktionsfähigkeit, Stabilität, Stromverbrauch, Wärmeentwicklung und Koexistenz mit anderen Prozessen mitdenken.

Die dafür zu betrachtenden Dinge bleiben diese vier.

Priorität
Affinität
P-Kerne / E-Kerne
Energiespareinstellungen

Und auf modernem Windows kommen dazu noch EcoQoS und der Efficiency mode.

Es gibt viel, worüber man sich Sorgen machen kann.

Doch diese Sorge muss nicht als bloße Unsicherheit bestehen bleiben.

Verwandeln Sie die Sorge in Messung.
Verwandeln Sie die Sorge in Logs.
Verwandeln Sie die Sorge in Design.
Verwandeln Sie die Sorge in Testbedingungen.

Dann wird Windows nicht zu einer bloß launischen Ausführungsumgebung, sondern zu einer Plattform für die Praxis, die sich durchaus lohnt zu beobachten.

Windows ist kein Echtzeit-Betriebssystem.
Trotzdem lassen sich, wenn Sie die Ausführungsumgebung verstehen und dafür entwerfen, Apps bauen, auf die man sich in der Praxis durchaus verlassen kann.

Und genau diese Schwierigkeit macht zugleich den Reiz der Windows-App-Entwicklung aus.

Quellen

• Das vollständige Beispielcode-Paket zu diesem Artikel (C# / PowerShell / Unit-Tests) - komurasoft-blog-samples (GitHub)
• Scheduling Priorities - Microsoft Learn
• SetProcessAffinityMask function - Microsoft Learn
• SetThreadAffinityMask function - Microsoft Learn
• CPU Sets - Microsoft Learn
• SYSTEM_CPU_SET_INFORMATION structure - Microsoft Learn
• Change the power mode for your Windows PC - Microsoft Support
• Power Policy Settings - Microsoft Learn
• P-states and C-States - Microsoft Learn
• Processor power management options - Microsoft Learn
• CPMinCores - Microsoft Learn
• Quality of Service - Microsoft Learn
• SetThreadInformation function - Microsoft Learn
• Reduce Process Interference with Task Manager Efficiency Mode - Microsoft DevBlogs

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.

Wie stellt man die CPU-Priorität ein?

Die Priorität wird in zwei Stufen festgelegt: der Prozess-Prioritätsklasse und der relativen Thread-Priorität. In der Win32-API gibt es dafür SetPriorityClass auf Prozessseite und SetThreadPriority auf Thread-Seite. In PowerShell lässt sich der Eigenschaft PriorityClass eines mit Get-Process abgerufenen Objekts ein Wert wie „AboveNormal“ zuweisen, in C# weist man PriorityClass von Process.GetCurrentProcess() den Wert ProcessPriorityClass.AboveNormal zu. Die dauerhafte Nutzung von HIGH_PRIORITY_CLASS oder REALTIME_PRIORITY_CLASS sollte jedoch vermieden werden, da sie die Reaktionsfähigkeit des gesamten Systems verschlechtert.

Warum wird die App nicht schneller, obwohl ich die Priorität erhöht habe?

Weil Priorität festlegt, „welcher Thread bei Konkurrenz zuerst läuft“, und keine Einstellung ist, die die CPU beschleunigt. Liegt die Ursache der Langsamkeit an Warten auf Festplatten-I/O, Warten auf das Netzwerk, Lock-Konkurrenz, GC-Pausen, einem blockierten UI-Thread, einem Scan durch Antivirensoftware oder daran, dass die CPU-Taktfrequenz durch Energiespareinstellungen gedrosselt ist, löst eine höhere Priorität das Problem nicht wirklich. Wichtig ist, zunächst die Verteilung der Verarbeitungszeit, den Energiezustand und die ausführende CPU aufzuzeichnen, um die Ursache einzugrenzen.

Was passiert, wenn ich EcoQoS über SetThreadInformation setze?

Geben Sie bei SetThreadInformation ThreadPowerThrottling und THREAD_POWER_THROTTLING_EXECUTION_SPEED an, teilen Sie dem Betriebssystem mit, diesen Thread als EcoQoS (ein auf Energiesparen ausgerichtetes QoS) zu behandeln. Da QoS die Kernauswahl und die Prozessorenergieverwaltung beeinflussen kann, lässt sich Arbeit wie Hintergrundsynchronisation oder nicht eilige Log-Aggregation auf die energiesparende Seite verschieben, ohne Vordergrund-Apps zu stören. Bei Arbeit, die direkt mit UI-Interaktionen, Kameraerfassung oder einem Regelzyklus zusammenhängt, sollten Sie dagegen vorsichtig sein. Mit StateMask gleich 0 kehren Sie zu leistungsorientiertem Verhalten zurück.

Was ist CPMinCores in powercfg?

CPMinCores ist eine Energieeinstellung im Zusammenhang mit Windows Core Parking und legt fest, wie viel Prozent der logischen Prozessoren zu einem beliebigen Zeitpunkt mindestens un-parked (nutzbar) bleiben müssen. Ein Wert von 100 % deaktiviert den Core-Parking-Algorithmus. Die aktuelle Einstellung lässt sich mit Administratorrechten über powercfg /q SCHEME_CURRENT SUB_PROCESSOR anzeigen. Schränken Sie die CPUs zusätzlich per Affinität ein, kann das mit den Entscheidungen von Core Parking nicht zusammenpassen, weshalb beides gemeinsam betrachtet werden sollte.

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.