مدخل إلى إعدادات المعالج لمطوّري تطبيقات Windows: الأولويّة، والانتماء (Affinity)، ونواة الأداء/نواة الكفاءة

أداء تطبيقات Windows لا يتحدّد بالكود وحده. حتّى نفس ملفّ .exe، قد يختلف الإحساس بالتشغيل باختلاف الحاسوب الذي يعمل عليه.

في حاسوب ما، تكون المعالجة الدوريّة مستقرّة.
وفي حاسوب آخر، تتأخّر أحياناً.
لا مشكلة عند التشغيل بالطاقة الكهربائيّة (AC)، لكنّه بطيء بشكل غريب عند التشغيل بالبطّاريّة.
رفعتَ الأولويّة في مدير المهامّ، لكنّه لم يصبح أسرع كما كنتَ تتوقّع.
ظننتَ أنّك حصرتَه في نواة الأداء (P-core)، لكن زمن المعالجة ما زال يتذبذب.
وعلى العكس، عند محاولة رفع الأداء، تستمرّ المروحة في الدوران وتصبح التطبيقات الأخرى بطيئة.

عند بناء تطبيقات Windows، تصادف ظواهر من هذا النوع «يصعب تفسيرها بالكود وحده».

الأشياء الأربعة التي نريد النظر إليها عندئذ هي:

وفي عالم Windows الحديث، تدخل في هذا الأمر أيضاً EcoQoS وميزة Efficiency mode في مدير المهامّ.

بعبارة أخرى، بيئة تنفيذ تطبيقات Windows ليست مجرّد «هل المعالج سريع أم بطيء».

متى يُنفَّذ
أين يُنفَّذ
على أيّ نوع من الأنوية يُنفَّذ
في أيّ حالة أداء يعمل المعالج
هل يراه نظام التشغيل «يركّز على الأداء» أم «يكفيه توفير الطاقة»

اجتماع كلّ هذه العناصر هو ما يحدِّد الاستجابة الفعليّة وزمن المعالجة.

في هذا المقال، نرتّب العلاقة بين الأولويّة والانتماء ونواة الأداء/نواة الكفاءة وإعدادات توفير الطاقة، وهي أمور يسهل إغفالها في تطوير تطبيقات Windows.

كما أنّ الكود الوارد في هذا المقال متاح على GitHub كمجموعة نماذج كاملة قابلة للبناء والتشغيل (مكتبة C# وعرض توضيحيّ للتعامل مع الأولويّة والانتماء، وسكربتات PowerShell، واختبارات وحدة).

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

1. الصورة الكلّيّة أوّلاً

أوّلاً، إن رسمنا الصورة الكلّيّة صارت كالتالي.

flowchart LR
  A["كود التطبيق"] --> B["مجدول Windows"]

  P["الأولويّة<br/>متى يسهل التنفيذ"] --> B
  AF["الانتماء / CPU Sets<br/>على أيّ معالج يجوز التنفيذ"] --> B
  Q["QoS / EcoQoS<br/>تركيز على الأداء أم على التوفير"] --> B

  B --> C["اختيار الخيط المنفَّذ"]
  C --> D["اختيار المعالج المنطقيّ المنفَّذ"]

  PE["نواة أداء / نواة كفاءة<br/>ميل إلى الأداء أم إلى التوفير"] --> D
  PM["وضع الطاقة / خطّة الطاقة / PPM<br/>التردّد والتعزيز وCore Parking"] --> D

  D --> R["الاستجابة الفعليّة<br/>زمن المعالجة<br/>الحرارة<br/>استهلاك البطّاريّة<br/>الأثر على التطبيقات الأخرى"]

المهمّ أنّ هذه العناصر ليست مستقلّة.

رفع الأولويّة يجعل التنفيذ أسهل.
لكن إن كان المعالج نفسه مضبوطاً نحو توفير الطاقة، فقد لا يزداد السرعة كما تتوقّع.

تضييق المعالجات بالانتماء قد يقلّل تنقّل الخيط.
لكن إن كانت الوجهة أنوية مائلة إلى التوفير، أو لم تتوافق مع Core Parking وإدارة الطاقة، فقد ينقلب الأمر إلى ضرر.

الميل إلى نواة الأداء قد يسرّع الحساب.
لكن إن مِلت بكلّ شيء إلى الجانب العالي الأداء، زادت الحرارة وضجيج المروحة واستهلاك البطّاريّة والأثر على العمليّات الأخرى.

ضبط أداء تطبيقات Windows ليس بحثاً بسيطاً عن «زرّ التسريع».

أيّ معالجة تريد تسريعها؟
وأيّ معالجة يجوز أن تبطؤ؟
هل تقدّم استجابة تفاعل المستخدم؟
أم تقدّم زمن اكتمال معالجة الخلفيّة؟
وإلى أيّ حدّ تقبل البطّاريّة والحرارة؟

يصير الأمر حديث تصميم.

في المخطّط، يشير الخطّ المتّصل إلى علاقة قائمة دائماً، ويشير الخطّ المتقطّع إلى علاقة مشروطة (شروط قيامها مذكورة في شرح كلّ علاقة في الصفحة التفصيليّة). القائمة الكاملة للعلاقات (المجموع 25، مع الأدلّة ودرجة اليقين) وتعريفات المفاهيم الرئيسة مجمّعة في صفحة تفاصيل خريطة المعرفة (باليابانية). البيانات: JSON-LD / Turtle

2. الأولويّة هي «متى يسهل التنفيذ»

في Windows، عندما توجد عدّة خيوط قابلة للتنفيذ، يقرّر المجدول «أيّ خيط يُحمَّل على المعالج تالياً». ما يؤثّر عندئذ هو الأولويّة.

تُحدَّد الأولويّة، بالنظر العريض، على مرحلتين.

فئة أولويّة العمليّة
  + الأولويّة النسبيّة للخيط
  = الأولويّة الأساسيّة للخيط

في Win32 API، يوجد SetPriorityClass لجانب العمليّة وSetThreadPriority لجانب الخيط.

للنظر إلى أولويّة العمليّة الجارية الآن من PowerShell، مثلاً:

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

ولرفع أولويّة عمليّة PowerShell الحاليّة:

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

وفي C# يمكن الكتابة كالتالي.

using System.Diagnostics;

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

ما ينبغي الانتباه إليه هنا أنّ الأولويّة ليست «إعداداً يسرّع المعالج». ما تتدخّل فيه الأولويّة هو أيّ خيط يُشغَّل أوّلاً عند وجود تنافس.

ليست إعداداً يرفع تردّد المعالج.
وليست إعداداً يختار نواة أداء.
وليست إعداداً يسرّع الإدخال/الإخراج.
وليست إعداداً يزيل انتظار القفل أو انتظار الشبكة.

لذلك فإنّ «رفعتُ الأولويّة ولم يصر أسرع» أمر شائع. مثلاً، إن كان سبب البطء ممّا يلي، فإنّ رفع الأولويّة لا يحلّ المشكلة جوهريّاً.

• انتظار إدخال/إخراج القرص
• انتظار الشبكة
• انتظار استجابة قاعدة البيانات
• تنافس الأقفال
• توقّف GC
• انسداد خيط واجهة المستخدم
• انتظار من جهة وحدة الرسوم أو المشغّل
• فحص الملفّات من برنامج مكافحة الفيروسات
• كبح تردّد المعالج نحو توفير الطاقة

كذلك لا يُستخدم HIGH_PRIORITY_CLASS أو REALTIME_PRIORITY_CLASS باستخفاف.

الخيط الذي يظلّ يعمل زمناً طويلاً بأولويّة عالية يصعب عليه تمرير زمن المعالج إلى الخيوط الأخرى.
إن اقتصر الأمر على تطبيقك فقد يُحتمل، لكنّه قد يسيء إلى استجابة النظام ككلّ.

الأولويّة أشبه بدواء.

تنفع في موضع نفعها.
لكنّها ليست ممّا يُزاد كمّه فيصير أفضل.

ما يُفكَّر فيه قبل رفع الأولويّة

قبل رفع الأولويّة، هناك ما يستحقّ التفكير أوّلاً.

المهمّ في تطبيقات Windows ليس العمل دائماً بأعلى أولويّة، بل تقديم المعالجة اللازمة، في التوقيت اللازم، وفي النطاق اللازم فقط.

3. الانتماء هو «على أيّ معالج يجوز التنفيذ»

إن كانت الأولويّة «متى يسهل التنفيذ»، فالانتماء هو «على أيّ معالج يجوز التنفيذ».

في Windows يمكن تحديد مجموعة المعالجات المنطقيّة القابلة للتنفيذ لعمليّة أو لخيط.

في Win32 API يوجد SetProcessAffinityMask للعمليّة وSetThreadAffinityMask للخيط.

للنظر إلى انتماء العمليّة من PowerShell، مثلاً:

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

ولأغراض التحقّق، لتضييق عمليّة PowerShell الحاليّة إلى أوّل أربعة معالجات منطقيّة:

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

0xF في الثنائيّ هو 1111.
أي أنّ المعنى السماح بالمعالجات المنطقيّة 0 إلى 3.

غير أنّ هذا مثال للتحقّق فحسب.

تضييق الانتماء قد يحسّن محلّيّة ذاكرة التخزين المؤقّت للمعالج، أو يقلّل تذبذب المعالجة الدوريّة.
وفي المقابل، يحبس الخيط في حيّز ضيّق كان Windows قادراً على إبعاده فيه إلى معالج فارغ.

يلزم الحذر خصوصاً في بيئات كهذه.

• اختلاط نواة أداء ونواة كفاءة
• SMT/Hyper-Threading (Simultaneous Multi-Threading؛ آليّة تُظهر نواة فيزيائيّة واحدة كعدّة معالجات منطقيّة)، حيث لا تكون مقابلة المعالج المنطقيّ للنواة الفيزيائيّة حدسيّة
• NUMA (Non-Uniform Memory Access؛ تكوين تختلف فيه مسافة الذاكرة كما يراها المعالج)
• تجاوز 64 معالجاً منطقيّاً ودخول Processor Group في الأمر
• تفعيل Core Parking
• تحكّم قويّ بالطاقة من OEM أو BIOS
• التشغيل على بيئة افتراضيّة

الانتماء إعداد يضع على النظام قيداً أقوى بمعنى «شغّل على هذه المعالجات فقط».

القيد قد يكون أداة تثبيت.
لكن إن أخطأت أغلقت مسارب الهروب.

اليوم يوجد أيضاً CPU Sets

قناع الانتماء التقليديّ قيد قويّ جدّاً.

ومن جهة أخرى، يوجد في Windows أيضاً آليّة اسمها CPU Sets.
CPU Sets واجهة API تتيح للتطبيق إبلاغ رغبته في المعالج بليونة أكبر.

في شرح Microsoft تُموضَع CPU Sets كانتماء «soft» متوافق مع إدارة طاقة نظام التشغيل.

هل تريد تثبيت المعالج بدقّة؟
أم تريد، بالتنسيق مع إدارة الطاقة والجدولة في نظام التشغيل، تقريب موضع التنفيذ تقريباً؟

هذا الفرق مهمّ.

لا تحاول حلّ كلّ شيء بـ SetProcessAffinityMask القديم. في تطبيقات Windows الحديثة يلزم التفكير أيضاً في CPU Sets وQoS.

4. نواة الأداء/نواة الكفاءة حديث أنّ «للمعالج أيضاً طبعاً»

في المعالجات الحديثة لا تكون كلّ الأنوية بنفس الأداء ونفس استهلاك الطاقة. المثال النموذجيّ نواة الأداء ونواة الكفاءة؛ باختصار، نواة الأداء تميل إلى الأداء ونواة الكفاءة تميل إلى الكفاءة.

غير أنّ تحديد المطوّر باستخفاف أنّ «المعالجات 0–7 نواة أداء و8–15 نواة كفاءة» خطر. ترتيب أرقام المعالجات قد يتغيّر بحسب المعالج وBIOS وإصدار Windows والبرامج الثابتة وإعداد OEM والبيئة الافتراضيّة.

في جانب Windows يوجد في معلومات CPU Sets مفهوم اسمه EfficiencyClass.
وهي قيمة تبيّن خصائص الكفاءة لمجموعة CPU Set في الأنظمة ذات المعالجات غير المتجانسة. في وثائق Microsoft، كلّما ارتفعت هذه القيمة حملت مجموعة CPU Set معالجات أسرع لكن أقلّ كفاءة في الطاقة.

إن أردت التعامل مع نواة الأداء/نواة الكفاءة، لا يكفي النظر إلى رقم المعالج وحده. للتعمّق فعلاً تلزم ملاحظات كهذه.

• النظر إلى EfficiencyClass عبر CPU Sets API
• النظر إلى معالج تنفيذ الخيط عبر Windows Performance Recorder / Analyzer (WPR / WPA؛ الأداتان القياسيّتان لأخذ أثر ETW وتحليله)
• النظر إلى الاتجاه في عرض المعالجات المنطقيّة في مدير المهامّ
• قياس زمن المعالجة على كلّ جهاز فعليّ
• المقارنة بين التشغيل على AC والتشغيل على البطّاريّة
• المقارنة مع تغيير وضع الطاقة

نواة الأداء/نواة الكفاءة ليست مواصفة عتاد فحسب. موضع التنفيذ الفعليّ يتحدّد باجتماعها مع مجدول Windows وQoS وإعدادات توفير الطاقة.

5. إعدادات توفير الطاقة تتعلّق بـ «إلى أيّ مدى يُدار المعالج بجدّيّة»

هذا الموضع مهمّ جدّاً في الميدان.

الأولويّة هي «أيّ خيط يُشغَّل أوّلاً».
الانتماء هو «على أيّ معالج يجوز التشغيل».
نواة الأداء/نواة الكفاءة هي «هل ذلك المعالج يميل إلى الأداء أم إلى التوفير».

وإعدادات توفير الطاقة تتعلّق بـ

بأيّ تردّد وحالة طاقة يُشغَّل المعالج أصلاً

أي أنّ أموراً كهذه تحدث.

رفعتَ الأولويّة.
ملتَ إلى نواة الأداء.
لكن إن كان إعداد الطاقة مائلاً إلى التوفير،
فقد لا يدور المعالج بجدّيّة.

وهذا حديث شديد الشبه بـ Windows.

في Windows 11 يمكن اختيار وضع الطاقة من تطبيق الإعدادات عبر «النظام > الطاقة والبطّاريّة».
التسمية تختلف بحسب البيئة والإصدار، لكنّ الاتجاه تقريباً كالتالي.

وفي خطط الطاقة القائمة منذ زمن يوجد Power Saver وBalanced وHigh Performance.
Balanced يضبط الأداء والاستهلاك حسب الطلب، وHigh Performance إعداد في اتجاه إخراج أقصى أداء مقابل الاستهلاك.

حتّى إن بدا الإعداد الذي يراه المستخدم بسيطاً، ففي الخلف إعدادات Processor Power Management، أي PPM.

6. P-state وC-state والتعزيز وEPP

المعالج لا يعمل دائماً بأقصى تردّد؛ له حالات لخفض استهلاك الطاقة.

P-state آليّة تخفض الاستهلاك بتغيير تردّد المعالج وجهده.
C-state آليّة يدخل بها المعالج حالة توفير أعمق بإيقاف بعض الوظائف عند الخمول.

إدارة طاقة Windows تستخدم هذه الآليّات للموازنة بين الأداء والاستهلاك.

لذلك فإنّ ظاهرة «أولويّة عالية لكنّه بطيء» ممكنة.

الخيط يُنفَّذ بالأفضلية.
لكن تردّد المعالج منخفض.
يدخل التعزيز بصعوبة.
EPP مائل إلى التوفير.
الأنوية المتاحة مقيَّدة بـ Core Parking.
النظام كلّه يعمل نحو التوفير عند التشغيل على البطّاريّة.

في مثل هذه الحالة، النظر إلى الأولويّة وحدها لا يوصل إلى السبب.

خصوصاً في المعالجة الدوريّة، ومعالجة الصور، والتحكّم بأجهزة القياس، ومعالجة الفيديو والصوت، والتقاط كاميرا USB، والاتّصال التسلسلي، لا يكفي متوسّط زمن المعالجة؛ المشكلة تكون في «التأخّر أحياناً».

المتوسّط سريع.
لكنّه يتأخّر مرّة كلّ 1000.
تلك المرّة تملأ المخزن المؤقّت.
تتجمّد الواجهة.
ينزاح التوقيت مع الجهاز.

في ظاهرة كهذه لا يكفي متوسّط استخدام المعالج.

يلزم النظر معاً إلى توزيع زمن المعالجة، والقيمة القصوى، والقيم الشاذّة، وحالة الطاقة، ومعالج التنفيذ، وحمل الخلفيّة.

7. Core Parking يتعلّق بـ «عدد الأنوية المتاحة»

في Windows آليّة اسمها Core Parking. وهي تحكّم في اتجاه إراحة المعالجات المنطقيّة غير المستخدمة.
عند انخفاض الاستخدام تُزاح بعض الأنوية إلى حالة طاقة منخفضة فيُكبح الاستهلاك.

في مواد Microsoft يُشرح CPMinCores كإعداد يحدّد أدنى نسبة من المعالجات المنطقيّة تُبقى un-parked، أي في حالة قابلة للاستخدام، في أيّ لحظة.
عند ضبط القيمة على 100% تُعطَّل خوارزميّة Core Parking.

المشكلة هنا هي الاجتماع مع الانتماء.

قيّدتَ بالانتماء «أريد التشغيل على هذه المجموعة من المعالجات».
لكن كيف تُعامل تلك الأنوية من جهة إدارة الطاقة مسألة أخرى.

في مواد موجَّهة إلى Windows Server أيضاً يُشرح أنّه إن كان للخيوط النشطة انتماء قويّ إلى جزء من معالجات عقدة NUMA، فقد لا يتوافق ذلك مع حكم Core Parking.

وهذا، كفكر، يصلح مرجعاً أيضاً على حاسوب العميل.

الانتماء يضع قيداً على المجدول.
وCore Parking يتعلّق بما تقرّره إدارة الطاقة عن «أيّ أنوية تُترك في حالة قابلة للاستخدام».

إن فكّرت في الاثنين منفصلين أخطأت السبب.

8. EcoQoS / Efficiency Mode آليّة تقول «هذه المعالجة يكفي فيها التوفير»

قديماً كان ضبط أداء تطبيقات Windows يتمحور حول رفع الأولويّة أو خفضها وتغيير الانتماء. لكنّ Windows الحديث فيه فكر آخر أيضاً. هو QoS.

QoS، Quality of Service، فكر يبيّن للخيط «إلى أيّ حدّ تُركَّز هذه المعالجة على الأداء، وإلى أيّ حدّ على توفير الطاقة».

في وثائق Microsoft، تبقى أولويّة الجدولة المؤشّر الرئيسيّ لتقرير أيّ خيط يُنفَّذ تالياً، بينما قد يؤثّر QoS في اختيار النواة وإدارة طاقة المعالج.

وEcoQoS خصوصاً آليّة لمعاملة معالجة ليس الأداء أهمّ ما فيها معاملة مائلة إلى التوفير.

في C++ يمكن، مثلاً بـ SetThreadInformation وThreadPowerThrottling، جعل الخيط الحاليّ EcoQoS.

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

وبالعكس، للعودة إلى التركيز على الأداء اضبط StateMask إلى 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));
}

عند الاستخدام من C# لا يوجد في مكتبة أصناف .NET نوع مخصَّص لضبط EcoQoS. تُستدعى SetThreadInformation عبر P/Invoke. التالي كتابة مفترضة لـ .NET 8.

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

internal static class EcoQos
{
    // THREAD_INFORMATION_CLASS の ThreadPowerThrottling
    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>今のスレッドを EcoQoS にする（false で性能重視へ戻す）。</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());
        }
    }
}

جانب الاستدعاء يصير كالتالي. EcoQoS إعداد على مستوى الخيط، لذا فالأأمن إنشاء خيط مخصَّص ووضعه وإزالته داخله.

using System.Threading;

// RunBackgroundMaintenance は、自分で用意する「急がない処理」です
var worker = new Thread(() =>
{
    EcoQos.SetForCurrentThread(true);
    try
    {
        RunBackgroundMaintenance();
    }
    finally
    {
        // 使い終わったら必ず戻す
        EcoQos.SetForCurrentThread(false);
    }
})
{
    IsBackground = true,
};

worker.Start();

ما ينبغي الانتباه إليه هنا هو عدم وضعه مباشرة على خيط Task.Run أو تجمّع الخيوط (thread pool). الهدف الذي يُضبَط هو خيط نظام التشغيل لا Task الجاري. إن وضعت EcoQoS على خيط التجمّع بقي مائلاً إلى التوفير حتّى عندما يُدار ذلك الخيط إلى عمل آخر تالياً. ومع انتقال الاستمرار عبر async / await إلى خيط آخر، قد يعمل أو لا يعمل خارج الفترة المقصودة.

EcoQoS ليست وظيفة تقول «وفِّر الطاقة في كلّ شيء». ما يناسبها مثلاً معالجات كهذه.

• المزامنة في الخلفيّة
• إنشاء الفهرس منخفض الأولويّة
• تجميع السجلّات غير المستعجل
• تحديث ذاكرة مؤقّتة لا ترتبط مباشرة بتفاعل المستخدم
• معالجة صيانة يكفي أن تنتهي لاحقاً

وفي المقابل ينبغي الحذر مع معالجات كهذه.

• معالجة مرتبطة مباشرة بتفاعل الواجهة
• التقاط الكاميرا
• معالجة الصوت
• معالجة تتعلّق بدورة التحكّم
• معالجة الحكم في جهاز فحص
• معالجة تصدير ينتظرها المستخدم
• معالجة تحتاج استجابة قريبة من الطابع الفوريّ

وEfficiency mode في مدير المهامّ أيضاً يتّصل بهذا الفكر.
في مدوّنة Performance Diagnostics من Microsoft يُشرح أنّ تفعيل Efficiency mode يخفض الأولويّة الأساسيّة للعمليّة إلى Low ويضبط QoS على EcoQoS.

أي أنّ Efficiency mode ليست مجرّد «أيقونة توفير طاقة»، بل آليّة تجمع خفض الأولويّة مع EcoQoS لحماية استجابة تطبيق المقدّمة وكفاءة الطاقة.

من منظور المطوّر هذا مهمّ جدّاً.

لأنّه يتيح تصميماً لا يقول لنظام التشغيل «أريد لهذه المعالجة أن تنتهي بسرعة» فحسب،
بل أيضاً «يكفي أن تعمل هذه المعالجة في نطاق لا يزعج المستخدم».

9. مخطّط قرار

الحديث حتّى هنا معقّد، لذا نضع مخطّط قرار عند التحقيق في أداء تطبيق Windows أو تذبذب دورته.

flowchart TD
  A["العَرَض<br/>بطء أو تذبذب دورة أو تجمّد واجهة أو ضجيج مروحة"] --> B["سجّل أوّلاً<br/>زمن المعالجة / القيمة القصوى / استخدام المعالج / حالة الطاقة / AC أو بطّاريّة / الحاسوب المستهدف"]
  B --> C{"هل المعالج هو السبب الرئيسيّ؟"}

  C -- "لا / غير معلوم" --> D["أكّد الإدخال/الإخراج والقفل وقاعدة البيانات والشبكة وGC ووحدة الرسوم والمشغّل<br/>أزل أزمنة الانتظار قبل الأولويّة والانتماء"]
  C -- "نعم" --> E{"هل تنافس المعالج مع العمليّات الأخرى قويّ؟"}

  E -- "نعم" --> F["انظر في الأولويّة<br/>لكن حدّد النطاق<br/>تجنّب الاستخدام الدائم لـ High/Realtime"]
  E -- "لا" --> G{"هل يميل إلى معالجات معيّنة؟"}

  G -- "نعم" --> H["أكّد الانتماء / CPU Sets<br/>هل التثبيت مفرط<br/>هل تنظر إلى نواة أداء/كفاءة وNUMA"]
  G -- "لا" --> I{"هل التردّد أو حالة الطاقة مريبة؟"}

  I -- "نعم" --> J["أكّد وضع الطاقة / خطّة الطاقة / PPM<br/>اشكّ في P-state / EPP / التعزيز / Core Parking"]
  I -- "لا" --> K{"هل معالجة الخلفيّة تزعج المقدّمة؟"}

  K -- "نعم" --> L["انظر في EcoQoS / Efficiency Mode / خفض الأولويّة<br/>أبعد المعالجة غير المستعجلة إلى جانب التوفير"]
  K -- "لا" --> M["راجع الخوارزميّة ودرجة التوازي وتصميم الطابور وتصميم خيط الواجهة"]

  F --> N["غيّر بنداً واحداً في كلّ مرّة وقِس A/B"]
  H --> N
  J --> N
  L --> N
  M --> N

  N --> O["لا تنظر إلى المتوسّط وحده<br/>انظر إلى القيمة القصوى والشاذّة والحرارة والأثر على التطبيقات الأخرى"]

المهمّ في هذا المخطّط ألا تلمس الإعدادات من البداية. سجّل أوّلاً.

• هل البطء دائم؟
• أم بطيء أحياناً؟
• طاقة كهربائيّة أم بطّاريّة؟
• ما وضع الطاقة؟
• هل صار Efficiency mode في مدير المهامّ؟
• هل استخدام المعالج مرتفع؟
• هل يرتفع التردّد؟
• أيّ خيط يستخدم المعالج؟
• كم تبلغ القيمة القصوى لزمن المعالجة؟
• هل للبرمجيّات المقيمة أو برنامج مكافحة الفيروسات علاقة؟

بعد ذلك غيّر واحداً واحداً.

غيّر الأولويّة.
غيّر الانتماء.
غيّر وضع الطاقة.
أضف EcoQoS.
افصل معالجة الخلفيّة.
أدخل طابوراً.
أخرجها من خيط الواجهة.

إن غيّرت عدّة أمور معاً لم تعد تعرف أيّها نفع.

10. أوامر التأكيد في الميدان

عندما يختلف سلوك تطبيق Windows بحسب البيئة، يفيد أن تكون قادراً أوّلاً على أخذ الحالة.

النظر إلى معلومات المعالج

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

النظر إلى خطّة الطاقة النشطة

powercfg /getactivescheme

النظر إلى إعدادات إدارة طاقة المعالج

powercfg /q SCHEME_CURRENT SUB_PROCESSOR

الإخراج طويل جدّاً، لكن يمكن تأكيد الإعدادات المتعلّقة بأدنى وأقصى حالة للمعالج، وEPP، والتعزيز، وCore Parking.
البنود الظاهرة تختلف بحسب البيئة.

صنع تقرير تشخيص كفاءة الطاقة

نفّذه من طرفيّة بصلاحيات مدير.

powercfg /energy

بعد قياس لمدّة معيّنة يُخرج تقرير HTML.
يصير مدخلاً للنظر إلى المشغّلات والأجهزة ودقّة المؤقّت وتوفير طاقة USB وعوائق النوم.

النظر إلى أولويّة العمليّة المستهدفة وانتمائها

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

التأكيد من مدير المهامّ

على جهاز العميل قد يتعذّر فتح PowerShell. إن أردت التأكيد من الواجهة الرسوميّة وحدها فانظر إلى المواضع التالية. التسمية تختلف حسب إصدار Windows، لذا نذكر الاسم الإنجليزيّ بين قوسين أيضاً.

وضع الكفاءة لا يُطبَّق على عمليّات نواة Windows. إيقافها يمسّ استقرار النظام.

كذلك وضع الكفاءة ليس تسمية عرض فحسب. في مدوّنة Performance Diagnostics من Microsoft يُشرح أنّ وضع الكفاءة يخفض الأولويّة الأساسيّة للعمليّة إلى Low ويضبط QoS على EcoQoS. أي أنّه يطبّق الإعدادين المكتوبين في الفصل 8 دفعة واحدة من الواجهة الرسوميّة.

علماً بأنّ ما يظهر في صفحة «التفاصيل» بمدير المهامّ هو أولويّة على مستوى العمليّة فحسب. لا تُعرض الأولويّة النسبيّة على مستوى الخيط ولا QoS لكلّ خيط. للنظر إلى ذلك خذ ETW بـ WPR / WPA.

النظر إلى حالة أداء المعالج

أسماء العدّادات المتاحة تختلف بحسب البيئة، لكنّ عدّادات الأداء التالية مفيدة كمرجع.

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

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

للنظر بجدّيّة، أخذ ETW عبر Windows Performance Recorder (WPR) وWindows Performance Analyzer (WPA) أوثق.
يمكن تتبّع تذبذب الدورة، وتبديل السياق، ومعالج التنفيذ، وDPC/ISR (Deferred Procedure Call / Interrupt Service Routine؛ معالجة مقاطعة المشغّل وتنفيذها المؤجَّل)، وإدخال/إخراج القرص، وتغيّر تردّد المعالج معاً.

11. في المعالجة شبه الفوريّة فكّر في الكلّ معاً

Windows ليس نظام تشغيل فوريّاً بالمعنى العامّ. غير أنّ تطبيقات Windows في الميدان قد تُطلب منها طبيعة قريبة من الفوريّة.

• أخذ صور من كاميرا USB بدورة ثابتة
• تبادل مع جهاز عبر اتّصال تسلسلي
• قراءة بيانات من جهاز قياس
• المزامنة مع PLC أو جهاز خارجيّ
• معالجة الصوت أو الفيديو
• إرجاع نتيجة الفحص خلال زمن معيّن
• تشغيل حساب ثقيل دون تجميد الواجهة

في معالجة كهذه لا يكفي سرعة الكود.

يلزم تصميم الخيوط.
ويلزم تصميم الطابور.
ويلزم السجلّ.
ويلزم المهلة (timeout).
ويلزم الضغط الخلفيّ (backpressure؛ آليّة تخفض تدفّق المنبع عمداً عندما يعجز المصبّ عن المعالجة).
ويلزم حسم إن كان التأخّر يُرمى أو يُنتظر أو يُعاد.

وفوق ذلك يلزم النظر إلى الأولويّة والانتماء ونواة الأداء/نواة الكفاءة وإعدادات توفير الطاقة.

خذ مثلاً خيط التقاط الكاميرا.

هذا الخيط قريب من تفاعل المستخدم وله دوريّة أيضاً.
لذلك لا ينبغي وضع EcoQoS.
للأولويّة قيمة في رفع درجة واحدة فقط خلال فترة الالتقاط. لكن لا تستخدم HIGH_PRIORITY_CLASS فأعلى بشكل دائم. يسيء ذلك إلى الواجهة والمعالجات الأخرى.
الانتماء يُثبَّت فقط عندما يظهر بالقياس ارتباط بين تذبذب الدورة وتنقّل المعالج. وإن ثبّتَّ فاختر جانب نواة الأداء بالنظر إلى EfficiencyClass لا إلى رقم المعالج. التثبيت على جانب نواة الكفاءة ينقلب ضرراً.
إن كان وضع الطاقة مائلاً إلى التوفير، ظهر تأخّر على البطّاريّة لم يظهر على الطاقة الكهربائيّة. لذلك أدخل شرط البطّاريّة حتماً في اختبار الأداء.

وماذا عن ضغط السجلّات القديمة؟

هذه ممثّل للمعالجة التي لا ينتظرها المستخدم.
عندئذ اخفض الأولويّة.
اجعلها EcoQoS.
شغّلها عند الخمول.
شغّلها على الطاقة الكهربائيّة فقط.
تصميم كهذا ألطف للتطبيق ككلّ.

لا تجعل كلّ معالجة «سريعة». افصل المعالجة التي ينبغي تسريعها عن المعالجة التي ينبغي ألا تزعج.

12. المبادئ الأساسيّة للتصميم

عند التعامل مع هذا الجانب في تطبيقات Windows هناك ستّة مبادئ.

1. لا تثبّت من البداية

الأفضل ألا تثبّت الأولويّة أو الانتماء بقوّة من البداية.

مجدول Windows في معظم الحالات يعمل جيّداً جدّاً.
قد يسوء الأمر بالعكس عندما يضع التطبيق قيوداً زائدة.

اصنع أوّلاً بشكل عاديّ.
قِس.
إن ظهرت مشكلة فضع فرضيّة.
غيّر تغييراً صغيراً.
قِس مرّة أخرى.

هذا هو الترتيب.

2. استخدم الأولويّة مؤقّتاً

الأولويّة العالية تُقصر على الفترة اللازمة.

أأمن من الإبقاء على أولويّة عالية دائماً أن

ترفعها قُبيل المعالجة المهمّة
وتعيدها عند الانتهاء

3. انظر في الانتماء في مرحلة متأخّرة

الانتماء إعداد قويّ.

قد ينفع عندما يُشتبه بأثر تذبذب الدورة أو تنقّل المعالج.
لكنّه ليس الإعداد الذي تلمسه أوّلاً.

خصوصاً إن تعدّدت أنواع حواسيب العملاء، فإنّ تثبيت رقم المعالج سلفاً خطر.

4. نواة الأداء/نواة الكفاءة «تُلاحظ» ولا «تُفرَض»

إن أردت التمييز بين نواة الأداء ونواة الكفاءة، فلاحظ أوّلاً على الجهاز الفعليّ.

لا تفرض برقم المعالج؛ انظر عبر CPU Sets وEfficiencyClass وETW والقياس الفعليّ.

5. اختبر على فرض إعدادات توفير الطاقة

أن يكون جهاز التطوير سريعاً لأنّه على طاقة كهربائيّة وإعداد عالي الأداء لا يكفي.

في بيئة العميل حالات كهذه شائعة.

• تشغيل دفتر ملاحظات على البطّاريّة
• Best power efficiency
• Energy saver
• أداة توفير طاقة خاصّة بالشركة المصنّعة (OEM)
• إعداد طاقة مثبَّت بسياسة مؤسّسة
• حاسوب رقيق ينخفض أداؤه بالحرارة
• محطّة عمل فيها برمجيّات مقيمة كثيرة

في اختبار الأداء تريد على الأقلّ فصل شروط كهذه.

6. انظر في EcoQoS لمعالجة الخلفيّة

المعالجة غير المرتبطة مباشرة بتجربة المستخدم قد يكون تقديم «عدم الإزعاج» فيها أولى من السعي إلى الأداء.

التطبيق الذي يشغّل كلّ شيء بأداء عالٍ قد يكون سريعاً.
لكنّه يزعج الأعمال الأخرى.
ويدير مروحة دفتر الملاحظات.
ويستهلك البطّاريّة.
فيصير في النتيجة تطبيقاً صعب الاستخدام.

في تطبيقات Windows، الجودة ليست السرعة وحدها بل أيضاً «حسن التعايش».

13. سوء فهم شائع

رفع الأولويّة يجعله أسرع

ليس بالضرورة.

إن كان السبب تنافس المعالج فقد ينفع.
لكن إن كان السبب انتظار إدخال/إخراج، أو انتظار قفل، أو تردّداً منخفضاً بسبب التوفير، أو تنفيذاً على جانب نواة كفاءة، فالأولويّة وحدها لا تكفي.

التثبيت على نواة الأداء صواب دائماً

ليس صواباً دائماً.

نواة الأداء عالية الأداء، لكنّ الحرارة والاستهلاك يزيدان أيضاً.
وقد تتنافس أيضاً مع معالجة مقدّمة مهمّة أخرى.

الأهمّ فصل المعالجة التي ينبغي إمالتها إلى نواة الأداء عن المعالجة التي تكفيها نواة الكفاءة.

إعدادات توفير الطاقة تفضيل مستخدم ولا علاقة للتطبيق بها

لها علاقة.

حتّى التطبيق نفسه يتغيّر أسلوب تنفيذه بحسب وضع الطاقة وخطّة الطاقة وEPP والتعزيز وCore Parking.

خصوصاً على دفتر الملاحظات يتغيّر السلوك بين الطاقة الكهربائيّة والبطّاريّة.

Efficiency mode مجرّد إبطاء

ليس مجرّد إبطاء.

هي آليّة لحماية استجابة تطبيق المقدّمة وكفاءة الطاقة عبر خفض الأولويّة وEcoQoS.
لمعالجة الخلفيّة غير المستعجلة تستحقّ التفكير بإيجابيّة بالأحرى.

لأنّه Windows فهو غير مستقرّ

هذه أيضاً نظرة خشنة.

Windows ليس نظام تشغيل فوريّاً.
لكن بفهم الجدولة وإدارة الطاقة وQoS والقياس والسجلّ وتصميم الخيوط يمكن تثبيته بما يكفي للميدان.

المشكلة ليست «مستحيل لأنّه Windows»، بل أنّك لا تنظر إلى أيّ طبقة يحدث فيها ماذا.

14. صمّم السجلّ قبل التنفيذ

مشكلات من هذا النوع قد تحدث في بيئة العميل وحدها. لذلك يفيد أن تتمكّن من إبقاء حدّ أدنى من معلومات التشخيص في جانب التطبيق.

مثلاً، أخرج إلى سجلّ التشخيص معلومات كهذه.

• إصدار التطبيق
• إصدار Windows
• اسم المعالج
• عدد المعالجات المنطقيّة
• طاقة كهربائيّة أم بطّاريّة
• متوسّط زمن المعالجة والحدّ الأقصى والمئين
• عدد مرّات تأخّر دورة المعالجة
• أولويّة الخيط المستهدف
• أولويّة العمليّة
• وجود إعداد انتماء من عدمه
• وجود إعداد EcoQoS من عدمه
• خطّة الطاقة عند الإقلاع
• عدد مرّات انتهاء مهلة المعالجة المستهدفة

عندما يقول العميل «بطيء أحياناً»، بلا سجلّ يصير الأمر مباراة تخمين. بوجود السجلّ يمكن وضع فرضيّة.

بطيء على البطّاريّة فقط
بطيء على حاسوب معيّن فقط
بطيء بعد الإقلاع مباشرة فقط
يبطؤ بعد 30 دقيقة
بطيء أثناء تشغيل تطبيقات أخرى فقط
تظهر قيمة شاذّة بدورة ثابتة

إن ظهرت فروق كهذه سهل عزل إن كان الأمر أولويّة أم انتماء أم إعداد طاقة أم حرارة أم انتظاراً آخر.

15. نظرة شركة كومورا سوفت

في تطوير تطبيقات Windows لا يكفي المنطق النظيف وحده.

أن يعمل على حاسوب العميل.
أن يعمل على محطّة الميدان.
أن يتعايش مع أجهزة محيطة قديمة.
أن يعمل في بيئة فيها برنامج مكافحة فيروسات وطابعة وسياسة داخليّة.
ألا ينهار مع إعداد توفير طاقة دفتر الملاحظات.
أن يُخرج أداءً حقّاً حيث يلزم الأداء.
ألا يزعج المستخدم في المعالجة غير المستعجلة.

لذلك الأفضل ألا ترى Windows مجرّد «نظام تشغيل صندوق أسود».

Windows يفكّر في كيف يشغّل الخيوط.
ويفكّر في على أيّ معالج يشغّل.
ويوازن الطاقة والأداء.
ويتعامل مع أنوية غير متجانسة مثل نواة الأداء/نواة الكفاءة.
ويحاول التمييز بين تطبيق المقدّمة ومعالجة الخلفيّة.

ينبغي للمطوّر ألا يعاكس ذلك، بل أن يبلغ قصده حيث يلزم.

هذه المعالجة تُنتظر من المستخدم.
هذه المعالجة يجوز أن تبطؤ قليلاً.
هذه المعالجة دورتها مهمّة.
هذه المعالجة يكفي أن تعمل بهدوء في الخلفيّة.
هذه المعالجة لا يجوز أن تزعج معالجة أخرى.

أنزل تصميماً كهذا إلى فهم الأولويّة والانتماء وQoS وإعدادات توفير الطاقة.

ما يُقرأ بعد ذلك

ما تناوله هذا المقال هو إعدادات جانب المعالج. عندما يكون سبب «البطء» خارج المعالج، المقالات التالية أقصر طريقاً.

16. الخلاصة

أداء تطبيقات Windows لا يتحدّد بالكود وحده.

حتّى إن رفعت الأولويّة، إن مال الانتماء إلى جانب نواة الكفاءة فلن يعمل كما تتوقّع.
وحتّى إن ملتَ إلى نواة الأداء، إن كان وضع الطاقة مائلاً إلى التوفير فلن يخرج المعالج أقصى أدائه.
وإن وضعت انتماء قويّاً دون التفكير في CPU Sets وQoS، أغلقت مسارب هروب إدارة الطاقة والمجدول في Windows.
وإن أمَلتَ الكلّ إلى الجانب العالي الأداء، زادت الحرارة وضجيج المروحة واستهلاك البطّاريّة والأثر على التطبيقات الأخرى.

في تطوير تطبيقات Windows يلزم التصميم لا للسرعة وحدها، بل أيضاً للاستجابة والاستقرار واستهلاك الطاقة والحرارة والتعايش مع العمليّات الأخرى.

وما ينبغي النظر إليه لذلك هو، من جديد، هذه الأربعة.

الأولويّة
الانتماء
نواة الأداء / نواة الكفاءة
إعدادات توفير الطاقة

وفي Windows الحديث ينضاف إليها EcoQoS وEfficiency mode.

ما يدعو إلى القلق كثير.

لكن لا يلزم إبقاء القلق قلقاً كما هو.

حوّل القلق إلى قياس.
حوّل القلق إلى سجلّ.
حوّل القلق إلى تصميم.
حوّل القلق إلى شروط اختبار.

عندئذ لا يبقى Windows مجرّد بيئة تنفيذ متقلّبة، بل يصير منصّة جديرة بالملاحظة وموجَّهة إلى الميدان.

Windows ليس نظام تشغيل فوريّاً.
ومع ذلك، إن فهمت بيئة التنفيذ وصمّمت وفقها، يمكن صنع تطبيق يُعتمد عليه بما يكفي في الميدان.

وصعوبة ذلك نفسها هي أيضاً طرافة تطوير تطبيقات Windows.

روابط مرجعية

• مجموعة عيّنات الشيفرة لهذا المقال (C# / PowerShell / اختبارات الوحدة) - 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

مقالات ذات صلة

أحدث المقالات التي تشترك في نفس الوسوم. عمّق فهمك بمواضيع مرتبطة.

أين يتصل هذا الموضوع

ترتبط هذه المقالة بشكل طبيعي بصفحات الخدمات التالية.

الأسئلة الشائعة

أسئلة شائعة حول موضوع هذه المقالة.

كيف تُضبَط أولويّة المعالج (CPU)؟

تُحدَّد الأولويّة على مرحلتين: فئة أولويّة العمليّة (process priority class) والأولويّة النسبيّة للخيط. في Win32 API توجد SetPriorityClass لجانب العمليّة وSetThreadPriority لجانب الخيط. في PowerShell يمكن ضبط الخاصّيّة PriorityClass للكائن المُستلَم عبر Get-Process إلى قيمة مثل "AboveNormal"، وفي C# يُسنَد ProcessPriorityClass.AboveNormal إلى PriorityClass الخاصّة بـ Process.GetCurrentProcess(). لكن ينبغي تجنّب الاستخدام الدائم لـ HIGH_PRIORITY_CLASS أو REALTIME_PRIORITY_CLASS لأنّه يُضعِف استجابة النظام بأكمله.

لماذا لا يصبح التطبيق أسرع بعد رفع الأولويّة؟

لأنّ الأولويّة إعداد يحدِّد «أيّ خيط يُشغَّل أوّلاً عند وجود تنافس»، وليست إعداداً يُسرِّع المعالج. إن كان سبب البطء انتظار إدخال/إخراج القرص، أو انتظار الشبكة، أو تنافس الأقفال (lock)، أو توقّف GC، أو انسداد خيط واجهة المستخدم، أو فحص برنامج مكافحة الفيروسات، أو انخفاض تردّد المعالج بسبب إعدادات توفير الطاقة، فإنّ رفع الأولويّة لا يحلّ المشكلة جوهريّاً. المهمّ أوّلاً هو تسجيل توزيع زمن المعالجة، وحالة الطاقة، والمعالج الفعليّ الذي نُفِّذَت عليه العمليّة، لعزل السبب.

ماذا يحدث عند ضبط EcoQoS عبر SetThreadInformation؟

عند تحديد ThreadPowerThrottling وTHREAD_POWER_THROTTLING_EXECUTION_SPEED في SetThreadInformation، يمكن إبلاغ نظام التشغيل بمعاملة ذلك الخيط كـ EcoQoS (جودة خدمة (QoS) تميل إلى توفير الطاقة). بما أنّ QoS قد يؤثِّر على اختيار النواة وإدارة طاقة المعالج، يمكن إبعاد معالجات مثل المزامنة في الخلفيّة أو تجميع السجلّات غير المستعجِل إلى الجانب الموفِّر للطاقة دون إزعاج التطبيق في المقدّمة. في المقابل، ينبغي التزام الحذر مع المعالجات المرتبطة مباشرةً بتفاعل واجهة المستخدم، والتقاط الكاميرا، والمعالجات المتعلّقة بدورة التحكّم. يمكن العودة إلى التركيز على الأداء بضبط StateMask إلى 0.

ما هو CPMinCores في powercfg؟

CPMinCores إعداد طاقة متعلّق بميزة Core Parking في Windows، ويحدِّد الحدّ الأدنى لنسبة المعالجات المنطقيّة (logical processors) الواجب إبقاؤها un-parked (في حالة قابلة للاستخدام) في أيّ لحظة. عند ضبط القيمة على 100%، تُعطَّل خوارزميّة Core Parking. يمكن التحقّق من الإعداد الحاليّ بتنفيذ powercfg /q SCHEME_CURRENT SUB_PROCESSOR بصلاحيّات المدير، وعند تضييق المعالجات عبر الانتماء (Affinity) قد لا يتوافق ذلك مع قرار Core Parking في بعض المواقف، لذا يلزم النظر إلى الاثنين معاً.

الملف الشخصي للمؤلف

صفحة الملف الشخصي لمؤلف المقالة.

غو كومورا

مؤسّس شركة كومورا سوفت ذ.م.م.

يركّز على تطوير برامج ويندوز، والاستشارات التقنية، والتحقيق في الأخطاء، ويتميّز في المشاريع التي تبقى فيها الأصول القديمة ناشطة، وفي تشخيص الأعطال التي يصعب تحديد سببها.