كيفيّة مقارنة سرعة إصدارات برنامج على Windows مقارنة صحيحة

تريد مقارنة الإصدارين A و B لبرنامج على Windows. أسوأ ما يمكن فعله عندئذ تشغيل كلّ منهما مرّة على نفس الجهاز والقول «يبدو أنّ B أسرع بنسبة 8%».

قد تكون تلك الـ 8% فرق شيفرة فعلاً. لكن في الواقع، أن تكون Power mode (وضع الطاقة) أو Power plan (خطّة الطاقة) أو الحرارة أو تحديث الخلفيّة أو فهرس البحث أو مسح الفيروسات أو الارتباط أو ترتيب التنفيذ أو حالة الذاكرة المؤقّتة هو حديث شائع في قياس Windows. يصير عملاً هادئاً تُصفَّى فيه الشروط واحداً واحداً.

flowchart TB
    accTitle: حقيقة «يبدو أسرع بنسبة 8%»
    accDescr: مخطّط يبيّن أنّ الفرق الظاهر من تشغيل مرّة واحدة قد يكون فرق شيفرة، لكن كثيراً ما تكون حقيقته الطاقة أو الحرارة أو الخلفيّة أو الذاكرة المؤقّتة، فيلزم عمل تصفية الشروط واحداً واحداً.
    one1["المقارنة بتشغيل مرّة لكلّ"] --> dif2["يظهر «يبدو أسرع بنسبة 8%»"]
    dif2 -->|"قد يكون"| code1["فرق شيفرة فعلاً"]
    dif2 -->|"الحقيقة الشائعة"| env1["طاقة وحرارة وضوضاء وذاكرة مؤقّتة"]
    env1 --> crush1["تصفية الشروط واحداً واحداً"]

الشكل 1: فرق المرّة الواحدة ليس حتماً فرق شيفرة، ولا يُقطَع به إلا بعد تصفية الشروط.

يلخّص هذا المقال كيفيّة مقارنة سرعة تنفيذ إصدارات مختلفة من برنامج على Windows بأقرب شكل ممكن إلى فرق الشيفرة. الهدف أساساً Windows 11، لكنّ معظم powercfg و start ونحوهما يُستخدم بالمثل على Windows 10.

مصطلحات تُمسَك مسبقاً

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

الخلاصة أوّلاً

حيلة رفع قابليّة إعادة الإنتاج، إن لُخِّصت، ستّ.

1. قرّر أوّلاً «ماذا تريد أن تقارن» البيئة التي ينبغي مواءمتها تتغيّر حسب هل تريد رؤية فرق الشيفرة أم تجربة المستخدم الفعليّة.

2. سجّل Power mode (وضع الطاقة) و Power plan (خطّة الطاقة) كشيئين منفصلين على Windows إن عومل هذا باستخفاف مالت المقارنة إلى مقارنة سياسة توفير طاقة نظام التشغيل.

3. افصل المرّة الأولى الباردة عن الحالة المستقرّة بعد الإحماء «الأولى وحدها سريعة» أو «النصف الثاني وحده بطيء» أمر غير نادر.

4. بدّل مثل A→B→A→B إن شغّلتَ A كلّه أوّلاً ثمّ B، أصبتَ انحياز الحرارة وحالة الخلفيّة.

5. انظر لا إلى المتوسّط وحده بل إلى الوسيط والتشتّت قيمة شاذّة واحدة تكفي لإمالة الصورة كلّها كثيراً. المتوسّط أضعف ممّا يُظَنّ.

6. إن صغر الفرق فاحفر السبب بـ ETW / WPR إن نوقش بالإحساس وحده بقي الادّعاءان بلا سند على خطّين متوازيين.

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

قرّر أوّلاً ماذا تريد أن تقارن

«مقارنة السرعة» لفظ واحد، لكنّها نوعان فعلاً.

1. مقارنة تريد رؤية فرق الشيفرة

مقارنة تريد معرفة هل صار التنفيذ نفسه أسرع بتغيير خوارزميّة أو بنية بيانات أو تحسين مترجم أو تحديث runtime.

هنا تقلّل ضوضاء البيئة قدر الإمكان. جلسة مخصّصة للقياس، وتثبيت Power mode (وضع الطاقة)، وإيقاف الإشعارات، وكبح فهرس البحث والمزامنة، وحتّى clean boot إن لزم.

2. مقارنة تريد رؤية تجربة المستخدم الفعليّة

مقارنة تريد معرفة السرعة التي يحسّ بها المستخدم على Windows اليوميّ بعد التوزيع.

هنا لا ينبغي محو الضوضاء الموجودة في الواقع كلّها. المقارنة في «بيئة يوميّة شبيهة» تشمل مزامنة OneDrive و Defender والإشعارات وإعداد الطاقة العاديّ تعطي نتيجة أقرب إلى الواقع.

خلط الاثنين يلوي النتيجة. وارد كالعادة أن يحدث «أسرع بنسبة 12% في المختبر، وضمن الخطأ في الواقع» أو «سريع في الواقع، ولا فرق في زمن CPU».

flowchart TB
    accTitle: لا تخلط نوعَي المقارنة
    accDescr: مخطّط يبيّن أنّ مقارنة تريد رؤية فرق الشيفرة ينبغي أن تقلّل ضوضاء البيئة قدر الإمكان، وأنّ مقارنة تريد رؤية تجربة المستخدم الفعليّة ينبغي أن تقيس في بيئة يوميّة تُبقي ضوضاء الواقع، وأنّ خلط الاثنين يلوي النتيجة.
    q5["ماذا تريد أن تقارن"] -->|"فرق الشيفرة"| lab1["بيئة مختبر قُلِّلت ضوضاؤها"]
    q5 -->|"تجربة المستخدم الفعليّة"| real1["بيئة يوميّة أُبقيت ضوضاؤها"]
    q5 -.->|"إن خُلطا"| twist2["تلتوي النتيجة"]

الشكل 2: البيئة التي ينبغي مواءمتها تنعكس حسب الغرض، فقرّر أوّلاً أيّ المقارنتين.

الأسباب الرئيسيّة لتذبذب النتيجة على Windows

أوّلاً نسرّد باستخفاف ما يذبذب النتيجة.

الخلاصة: حتّى «نفس جهاز Windows»، إن لم تتوافق الشروط فالتجربة أخرى.

flowchart TB
    accTitle: إن لم تتوافق الشروط فالتجربة أخرى
    accDescr: مخطّط يبيّن أنّ القياس على نفس جهاز Windows، إن لم تتوافق شروط متعدّدة الطبقات من العتاد إلى الطاقة والحرارة والخلفيّة وشروط البناء، تجربة أخرى فعليّاً، وأنّ المقارنة لا تقوم إلا بعد تثبيت الشروط وتسجيلها.
    same1["القياس على نفس جهاز Windows"] -.->|"الشروط غير متوافقة"| oth1["تجربة أخرى فعليّاً"]
    same1 -->|"تثبيت شروط متعدّدة الطبقات وتسجيلها"| cmp1["تصير مقارنة لأوّل مرّة"]

الشكل 3: حتّى إن كان الجهاز نفسه، لا تقوم المقارنة إن لم تتوافق الشروط عبر الطبقات.

افصل التفكير في Power mode (وضع الطاقة) عن Power plan (خطّة الطاقة)

هذه نقطة مهمّة جدّاً.

على Windows يوجد Power mode (وضع الطاقة) في تطبيق الإعدادات، و Power plan (خطّة الطاقة) التقليديّ (خطّة الطاقة الظاهرة في powercfg). تشابه المظهر يسهّل خلطهما، لكن المعاملة المستخفّة تجعل شروط المقارنة غامضة وتُفقَد قابليّة إعادة إنتاج النتيجة.

في تطبيق إعدادات Windows يمكن اختيار Power mode من Settings > System > Power & battery. وثائق Microsoft تقول إنّه يمكن تبديل Best power efficiency و Balanced و Best performance لكلّ من Plugged in / On Battery. ثمّ إن تغيّر Power mode أثّر أيضاً في إعدادات الطاقة خلفه وفي سلوك PPM (Processor Power Management). أي أنّ اختلاف هذا وحده قد يغيّر سياسة إيقاف الأنوية وتحجيم الأداء.

من جهة أخرى، Power plan خطط طاقة تقليديّة مثل Balanced و High performance. يمكن تأكيدها بـ powercfg /list أو powercfg /getactivescheme.

ما يعقّد الأمر هنا وجود طبقة فوقيّة لـ Power mode (وضع الطاقة) و Power plan (خطّة الطاقة) كليهما على Windows. إن رُسمت العلاقة صارت كالتالي.

flowchart TB
    subgraph upper["الطبقة العليا: Power mode - طبقة فوقيّة"]
        direction LR
        M1["Best power efficiency"]
        M2["Balanced"]
        M3["Best performance"]
    end

    subgraph lower["الطبقة السفلى: Power plan - خطّة الطاقة"]
        direction LR
        P1["Balanced"]
        P2["High performance"]
        P3["custom plan"]
    end

    UI["تطبيق الإعدادات<br/>Power mode في Power and battery"] --> upper
    CLI["التبديل بـ powercfg /setactive"] --> lower
    upper --> PPM["إعداد الطاقة الذي يفعل فعله فعلاً<br/>PPM ومجموعات الرسوم الفرعيّة"]
    lower --> PPM
    AC["تغذية AC أم بطاريّة"] --> PPM
    PPM --> RESULT["الحدّ الأعلى للتردّد / إيقاف الأنوية / تحجيم الأداء"]

الشكل 4: طبقتا Power mode (طبقة فوقيّة) و Power plan مع AC/DC تجتمع لتقرير إعداد الطاقة الذي يفعل فعله فعلاً.

النظر إلى الطبقة العليا وحدها أو السفلى وحدها لا يقرّر السلوك الفعليّ. لذلك سجّل مع نتيجة القياس على الأقلّ:

• AC أم بطاريّة
• ما هو Power mode
• ما هو Active power plan

نتيجة قياس بلا هذه الثلاث لا يمكن استعادة شروطها عند مراجعتها لاحقاً.

flowchart TB
    accTitle: ثلاث تُسجَّل في الحدّ الأدنى
    accDescr: مخطّط يبيّن أنّه إن لم تُسجَّل مع النتيجة ثلاث: AC أم بطاريّة، وما هو Power mode، وما هو Active power plan، تعذّرت استعادة الشروط عند المراجعة لاحقاً.
    r1["AC أم بطاريّة"] --> rec2["تُسجَّل مع النتيجة"]
    r2["Power mode"] --> rec2
    r3["Active power plan"] --> rec2
    rec2 --> rst1["يمكن استعادة الشروط لاحقاً"]

الشكل 5: ثلاث محيط الطاقة حدّ أدنى من التسجيل: إن لم تُكتَب صارت النتيجة غير قابلة لإعادة الإنتاج.

شروط الطاقة التي ينبغي تثبيتها أوّلاً

1. الحاسوب المحمول يُقارَن حتماً مع اتّصال AC تشغيل البطاريّة يسهّل دخول قيود غير مقصودة.

2. ثبّت Power mode لغرض القياس جرّب أوّلاً Best performance.

3. سجّل Active power plan أبقِ القيمة الحاليّة بـ powercfg.

powercfg /list
powercfg /getactivescheme

خرج powercfg /list يظهر في وثائق Microsoft بالشكل التالي. تُلحَق * بنهاية سطر الخطّة النشطة. في بيئة يابانيّة تظهر العناوين وأسماء الخطط باليابانيّة.

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

انسخ GUID الظاهر هنا كما هو إلى حقل power_plan في ملفّ النتيجة. النقطة إبقاؤه GUID لا اسماً. فقد تكون خطّة أخرى منسوخة أو مخصّصة تحمل نفس اسم «متوازن».

1. بدّل إلى High performance إن لزم

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

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

هل يمكن تبديل Power mode بأمر؟

هذا موضع يسهل التعثّر فيه. في قائمة خيارات سطر الأوامر المنشورة لـ powercfg لا يوجد خيار يعيد اختيار Power mode (الطبقة الفوقيّة) نفسه. الإجراء النظاميّ للتبديل من Settings > System > Power & battery في تطبيق الإعدادات.

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

• تمرير اسم مستعار للطبقة الفوقيّة ومجموعة فرعيّة إلى powercfg /q يقرأ إعداد جهة الطبقة الفوقيّة
• powercfg /setacvalueindex و /setdcvalueindex يُستخدمان أيضاً مع مخطّط الطبقة الفوقيّة
• إن لم يُحدَّد مخطّط، يصير الهدف الطبقة الفوقيّة النشطة حالياً (أو خطّة الطاقة الحاليّة إن لم توجد طبقة فوقيّة)
• قائمة الأسماء المستعارة تُؤكَّد بـ powercfg /aliases

أي أنّ ما يمكن بالأوامر هو «قراءة محتوى الطبقة الفوقيّة الفاعلة الآن وتعديله»، لا تغيير «أيّ طبقة فوقيّة تُختار». كإجراء إعادة إنتاج للقياس، الواقعيّ تثبيت Power mode يدوياً في تطبيق الإعدادات وكتابة قيمته مع النتيجة. صرّح في دليل الإجراءات بأنّ «Power mode = Best performance» وأكّد على الشاشة في كلّ تنفيذ.

flowchart TB
    accTitle: ما يستطيعه powercfg وما لا يستطيعه
    accDescr: مخطّط يبيّن أنّ powercfg يدعم قراءة قيم إعداد الطبقة الفوقيّة الفاعلة الآن وكتابتها، لكن لا خيار يغيّر أيّ طبقة فوقيّة تُختار، لذا الواقعيّ تثبيت Power mode يدوياً في تطبيق الإعدادات وإبقاء القيمة.
    pc1["powercfg"] -->|"يستطيع"| rw1["قراءة محتوى الطبقة الفوقيّة وتعديله"]
    pc1 -.->|"لا يستطيع"| sel1["تغيير أيّ طبقة فوقيّة تُختار"]
    sel1 --> hand1["تثبيت يدويّ في تطبيق الإعدادات وتسجيل"]

الشكل 6: اختيار الطبقة الفوقيّة لا يُغيَّر بأمر، فثبّته يدوياً وسجّله.

«High performance لا يظهر» أمر وارد

هذا أيضاً موضع تعثّر. وثائق Microsoft تقول إنّ الأجهزة الداعمة لـ Modern Standby لا يُسمَح فيها إلا بـ Balanced أو خطط مشتقّة من Balanced. لذلك ليس «High performance غير موجود، أهذا عطل؟» بل يحتمل أن يكون كذلك بحكم تصميم ذلك الطراز.

كذلك توجّه Microsoft: «إن تعذّر تغيير Power mode فقد تكون خطّة مخصّصة مختارة، فجرّب اختيار Balanced أوّلاً». إن لم تتحرّك واجهة Power mode فالأسرع الشكّ هنا.

flowchart TB
    accTitle: كيف تُرى حالة غياب High performance
    accDescr: مخطّط يبيّن أنّ الأجهزة الداعمة لـ Modern Standby لا يُسمَح فيها إلا بـ Balanced أو خطط مشتقّة منه فغياب High performance تصميم، وأنّ تعذّر تغيير واجهة Power mode يدعو أوّلاً إلى الشكّ في اختيار خطّة مخصّصة.
    nohp1["High performance غير موجود"] --> ms1["إن دعم Modern Standby فهذا وفق التصميم"]
    nomv1["واجهة Power mode لا تتحرّك"] --> cst1["اشكك في إمكان خطّة مخصّصة"]
    cst1 --> bl1["جرّب اختيار Balanced أوّلاً"]

الشكل 7: غياب الخطّة أو جمود الواجهة ليسا حتماً عطلاً؛ انظر أوّلاً إلى تصميم الطراز واختيار الخطّة.

أخمد ضوضاء الخلفيّة

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

أوّلاً أعد التشغيل وانتظر حتّى يهدأ

بعد تغيير الإعداد أعد التشغيل مرّة، ولا تشغّل فور تسجيل الدخول، بل انتظر دقائق. فور الإقلاع ما زال التحديث والفهرس والمزامنة و Defender والمقيمات المتنوّعة هائجة.

flowchart TB
    accTitle: أعد التشغيل وانتظر حتّى يهدأ
    accDescr: مخطّط يبيّن الإجراء: بعد تغيير الإعداد أعد التشغيل مرّة، وفور الإقلاع يعمل التحديث والفهرس والمزامنة و Defender وغيرها، لذا لا تشغّل فور تسجيل الدخول بل انتظر دقائق ثمّ ابدأ القياس.
    chg1["تغيير الإعداد"] --> rb1["إعادة تشغيل مرّة"]
    rb1 --> wt1["بعد تسجيل الدخول انتظر دقائق"]
    wt1 --> ms2["ثمّ ابدأ القياس"]
    rb1 -.-> nzz1["فور الإقلاع ما زال المقيم هائجاً"]

الشكل 8: بدء القياس بعد أن يهدأ نشاط الخلف بعد إعادة التشغيل.

للمقارنة الصارمة استخدم clean boot

Microsoft توجّه إلى إجراء يمكن به أدنى تكوين لبدء التشغيل عبر clean boot. الأسلوب إيقاف الخدمات غير التابعة لـ Microsoft في msconfig، وتعطيل Startup apps في Task Manager.

هذا قويّ في تقليل الضوضاء. لكنّه يبتعد عن بيئة الاستخدام اليوميّ، فيناسب «مقارنة مختبر لرؤية فرق الشيفرة».

أكتم الإشعارات

لافتات إشعارات Windows تبدو خفيفة وتعيق على غير توقّع. لا الإعاقة البصريّة وحدها، بل قد تغيّر توقيت التنفيذ والتركيز ونشاط التطبيقات في الخلف.

فعّل Do not disturb يدوياً، أو على الأقلّ اقطع الإشعارات أثناء القياس.

اكبح فهرس البحث والمزامنة

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

• أخرج مجلّد القياس من أهداف البحث
• أوقف مزامنة OneDrive / Dropbox / Google Drive ونحوها
• أغلق المتصفّح و Teams و Discord و Slack

هذا المحيط بلا بريق، لكن حين ينفع ينفع كثيراً.

flowchart TB
    accTitle: ضوضاء تصيب قياساً يلمس ملفّات كثيرة
    accDescr: مخطّط يبيّن أنّ قياس نوع يقرأ ويكتب كمّاً كبيراً من الملفّات يصيبه فهرس البحث ومزامنة السحابة والتطبيقات المقيمة، فتقلّل الضوضاء باستبعاد أو إيقاف.
    ix1["فهرس البحث"] --> hit1["يصيب قياساً يلمس ملفّات كثيرة"]
    sy1["مزامنة السحابة"] --> hit1
    ap2["تطبيقات مقيمة"] --> hit1
    hit1 --> cutn1["تقليل الضوضاء باستبعاد وإيقاف"]

الشكل 9: كلّما كثر قراءة الملفّات وكتابتها في القياس، نفع إيقاف الفهرس والمزامنة.

مقارنة لا توحّد الحرارة تقارن الحرارة في الغالب

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

flowchart TB
    accTitle: آليّة تغيّر الشروط بالحرارة
    accDescr: مخطّط يبيّن أنّ CPU و GPU يتغيّر تردّد عملهما بين البرودة وبعد الإحماء فتتغيّر شروط نفس الشيفرة في كلّ تنفيذ، وأنّ مقارنة لا توحّد الحرارة تقارن الحرارة في الغالب.
    cold1["تنفيذ في حالة باردة"] --> hot1["بعد الإحماء يتغيّر التردّد"]
    hot1 --> vary1["تتغيّر الشروط في كلّ تنفيذ"]
    vary1 -.-> heatc1["مقارنة بلا توحيد تقارن الحرارة"]

الشكل 10: التردّد يتحرّك بالحرارة، فإن لم تُوحَّد شروط الحرارة قارنتَ التبريد لا الشيفرة.

قواعد ينبغي الالتزام بها

• وحّد حرارة الغرفة قدر الإمكان
• ثبّت وضع الحاسوب المحمول
• ثبّت تكوين محوّل AC والمنصّة والشاشة الخارجيّة
• لا تعمل عملاً ثقيلاً قبل القياس
• قِس المرّة الأولى والحالة المستقرّة منفصلتين

اجعل ترتيب التنفيذ متناوباً

تجنّب 10 مرّات لـ A ثمّ 10 مرّات لـ B. يركب انحياز الحرارة والذاكرة المؤقّتة ونشاط الخلفيّة.

الموصى به واحد ممّا يلي.

• A B A B A B ...
• A B B A A B B A ...
• ولّد ترتيباً عشوائيّاً مسبقاً ونفّذ بذلك الترتيب

flowchart TB
    accTitle: ترتيب التنفيذ يغيّر كيفيّة ركوب الانحياز
    accDescr: مخطّط يبيّن أنّ تشغيل A كلّه أوّلاً ثمّ تشغيل B يركب انحياز الحرارة والذاكرة المؤقّتة ونشاط الخلفيّة على طرف واحد، لذا يُبدَّل أو يُنفَّذ بترتيب عشوائيّ لتوزيع الانحياز على الطرفين.
    seq1["A كلّه ثمّ B كلّه"] --> bias1["يركب الانحياز على طرف واحد"]
    alt1["تبديل A B A B أو ترتيب عشوائيّ"] --> even1["يتوزّع الانحياز على الطرفين"]
    even1 --> fair1["يمكن نزع أثر الترتيب من الفرق"]

الشكل 11: تجميع الترتيب يقارن الانحياز معه، فنفّذ متناوباً أو عشوائيّاً.

ما تقيسه يغيّر معنى «أسرع»

حشر «أسرع» في رقم واحد يُحدث حادثاً في الغالب. المؤشّرات النموذجيّة التي ينبغي النظر إليها على Windows ثلاث.

1. Wall-clock time (الزمن الحقيقيّ)

الوقت الذي ينتظره المستخدم. الأقرب إلى الإحساس من طرف إلى طرف، فأوّل قيمة تُنظَر هي هذه.

على Windows يمكن استخدام QueryPerformanceCounter (QPC) للحصول على وقت عالي الدقّة. في الشيفرة المُدارة الأساس استخدام عائلة Stopwatch. التطلّع إلى الملّي ثانية بـ DateTime.Now غير محصَّن قليلاً كما ينبغي.

2. CPU time (زمن المستخدم + النواة)

الزمن الذي استخدمت فيه العمليّة CPU فعلاً، يمكن الحصول عليه بـ GetProcessTimes.

هذا مريح لـ رؤية كفاءة الحساب. مثلاً إن صار wall-clock أسرع ولم يتغيّر CPU time، يحتمل أن تكون الذاكرة المؤقّتة أو I/O أو زمن الانتظار أو الجدولة هي التي تفعل.

3. Cycle count (عدد دورات CPU)

بـ QueryProcessCycleTime يمكن أخذ عدد دورات CPU للعمليّة كلّها.

هذا أيضاً مؤشّر لرؤية عمل CPU، لكنّه يُظهر وجهاً آخر غير wall-clock. مريح خصوصاً حين تريد رؤية «زمن الانتظار سواء، لكن هل خفّ جزء الحساب».

flowchart TB
    accTitle: اختلاف الوجه الذي تراه المؤشّرات الثلاثة
    accDescr: مخطّط يبيّن أنّ wall-clock time وقت انتظار المستخدم، و CPU time الزمن الذي استخدمت فيه العمليّة CPU فعلاً، و cycle count عدد دورات CPU، وجوه مختلفة، وأنّ محتوى السرعة لا يُقرأ إلا بالجمع.
    spd1["رؤية محتوى «أسرع»"] --> w1["wall-clock: وقت الانتظار"]
    spd1 --> u1["CPU time: زمن CPU المستخدم"]
    spd1 --> cy1["cycle: ثقل جزء الحساب"]
    w1 -.-> mixr1["تخمين السبب بالجمع"]

الشكل 12: لا تحشر في رقم واحد؛ اقرأ معنى السرعة بجمع المؤشّرات الثلاثة.

priority و affinity و NUMA آخر الوسائل

هذا المحيط قد ينفع. لكن لمسه من البداية لأنّه ينفع يسهّل صنع ظاهرة أخرى.

قِس أوّلاً كالعادة

إن ظهر فرق في الحالة الافتراضيّة فذلك الفرق نفسه ذو قيمة. إدخال /high أو /affinity فجأة يعني إدخال «شروط لا تحدث على Windows الفعليّ».

flowchart TB
    accTitle: priority و affinity آخر الوسائل
    accDescr: مخطّط يبيّن أنّ القياس أوّلاً في الحالة الافتراضيّة، فإن ظهر فرق فذلك الفرق نفسه ذو قيمة، وأنّ تثبيت الأولويّة أو الارتباط فجأة يُدخل شروطاً لا تحدث على Windows الفعليّ، لذا إن استُخدم فبأخرة بعد توضيح الغرض.
    def1["القياس أوّلاً في الحالة الافتراضيّة"] --> val1["إن ظهر فرق فذلك الفرق ذو قيمة"]
    early1["/high أو /affinity فجأة"] -.-> art1["إدخال شروط لا تحدث في الواقع"]
    val1 -->|"إن لزم فقرّر الغرض"| lastr1["التثبيت كآخر وسيلة"]

الشكل 13: الأولويّة والارتباط تُستخدمان بغرض بعد إنجاز القياس في الافتراضيّ.

إن استخدمتَ فوضّح الغرض

• /high: تريد تقليل إعاقة العمليّات الأخرى
• /affinity: تريد تثبيت توزيع CPU للمقارنة
• تحكّم NUMA: تريد مواءمة محليّة الذاكرة أيضاً على جهاز كبير

أمر start في Windows يمكنه الإقلاع مع priority class أو affinity mask.

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

لكن توقّف عن /realtime

/realtime يمكن استخدامه، لكن الأولى عدم استخدامه. يميل إلى صنع حادث آخر لا إلى إزالة الضوضاء.

إجراء قياس موصى به

نلخّص إجراءً سهل التشغيل الفعليّ بناءً على ما سبق.

إجراء مقارنة أقرب إلى المختبر

1. ثبّت هدف المقارنة
   • commit hash / build number
   • compiler / runtime version
   • Debug / Release
   • وجود السجلّ و assert والتتبّع
2. ثبّت شروط الجهاز
   • Windows build
   • BIOS / UEFI version
   • driver version
   • اتّصال AC
   • حرارة الغرفة وطريقة الوضع
3. ثبّت شروط الطاقة
   • قرّر Power mode
   • سجّل Active power plan
4. أعد التشغيل
5. انتظر دقائق قبل القياس
6. clean boot إن لزم
7. أدخل إحماء (warm-up)
8. بدّل A / B
9. أمّن العدد
10. أبقِ الوسيط والحدّ الأدنى والحدّ الأقصى و p95
11. احفظ البيانات الخامّ
12. إن صغر الفرق فخذ ETW / WPR

كم مرّة تشغّل

نحدّد أيضاً مؤشّراً لـ «تأمين العدد» في 9. التالي ليس حلاً إحصائيّاً صارماً بل موضع هبوط في العمل.

الوقت اللازم يُقدَّر بـ زمن التنفيذ الواحد × العدد × عدد الإصدارات + الإحماء. معالجة 30 ثانية مرّة، 30 مرّة لكلّ من A / B، حساب حوالي 35 دقيقة مع الإحماء. إن لم يكن هذا واقعيّاً فأقوم من تقليص العدد قطع هدف القياس أصغر (عزل المرحلة الثقيلة وحدها).

إن تردّدت أين تتوقّف، فأوضح أسلوب زيادة العدد مع النظر إلى مسار الوسيط، والتوقّف حيث لا يتحرّك الوسيط رغم الزيادة.

flowchart TB
    accTitle: أين تتوقّف في العدد
    accDescr: مخطّط يبيّن طريقة عمليّة لتقرير عدد التنفيذات: زيادة العدد مع النظر إلى مسار الوسيط، والتوقّف حيث لا يتحرّك الوسيط رغم الزيادة.
    add2["زيادة العدد والتشغيل"] --> mdz1["النظر إلى مسار الوسيط"]
    mdz1 -->|"ما زال يتحرّك"| add2
    mdz1 -->|"لا يتحرّك رغم الزيادة"| stop1["التوقّف هناك"]

الشكل 14: حتّى إن تعذّر تثبيت العدد مسبقاً، يمكن اتّخاذ نقطة استقرار الوسيط موضع توقّف.

بنود يفيد إبقاؤها لاحقاً

في CSV أو JSON القياس، إبقاؤها على الأقلّ التالية قويّ.

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

إن أمكن فالتالي أيضاً مريح.

cpu_package_temp_start_c,cpu_package_temp_end_c,affinity_mask,priority_class,windows_build,driver_version

في القياس، إمكان التفسير لاحقاً أهمّ أحياناً من القياس نفسه.

انظر لا إلى المتوسّط وحده بل إلى الوسيط والتوزيع

المتوسّط مريح، لكنّه ينكسر بسهولة في قياس Windows. مرّة واحدة دخل Defender، أو ظهر إشعار، أو ضربت عمليّة أخرى SSD، فيُسحَب المتوسّط.

flowchart TB
    accTitle: المتوسّط يُسحَب بقيمة شاذّة
    accDescr: مخطّط يبيّن أنّ دخولاً واحداً لمسح Defender أو إشعار أو I/O من عمليّة أخرى يكفي لسحب المتوسّط، لذا يُنظَر بالتوزيع بجعل الوسيط محوراً مع جمع p95 و p99 و min/max.
    once3["ضوضاء تدخل مرّة واحدة"] --> avg1["يُسحَب المتوسّط"]
    med2["جعل الوسيط محوراً"] --> dist1["النظر أيضاً إلى p95 / p99 و min / max"]
    dist1 --> robust1["تصير قراءة أقوى أمام القيمة الشاذّة"]

الشكل 15: المتوسّط ينكسر بضوضاء مرّة واحدة، فاقرأ بجمع الوسيط والتوزيع.

الموصى به هذا الجمع.

• الوسيط: انظر إلى هذا أوّلاً
• p95 / p99: انظر هل ساء الذيل
• min / max: انظر كيفيّة الشذوذ
• مربّع شارب أو مخطّط انتشار: ينفع حين يصغر الفرق

كيف تقرأ حين يظهر فرق

تفسير النتيجة يسهل بالجمع.

wall-clock وحده أسرع

قد يكون تحسين I/O أو زمن انتظار أو ذاكرة مؤقّتة أو جدولة.

CPU time و cycle كلاهما انخفض

يحتمل بقوّة أن يكون التنفيذ نفسه أخفّ.

المرّة الأولى وحدها بطيئة / سريعة

فرق cold / warm. اشكك في الإقلاع والتهيئة وتوليد الذاكرة المؤقّتة و JIT.

يزداد البطء كلّما تكرّر التشغيل

اشكك في الحرارة والخنق وضغط الذاكرة ونشاط الخلفيّة.

flowchart TB
    accTitle: قراءة السبب من نمط الفرق
    accDescr: مخطّط يبيّن قراءة: إن كان wall-clock وحده أسرع فانتظار أو I/O، وإن انخفض CPU time و cycle أيضاً فالتنفيذ أخفّ، وإن اختلفت الأولى وحدها ففرق cold و warm، وإن بطؤ في النصف الثاني فحرارة أو نشاط خلف.
    pt2["النظر إلى كيفيّة ظهور الفرق"] -->|"الزمن الحقيقيّ فقط"| c1a["انتظار و I/O"]
    pt2 -->|"انخفض زمن CPU أيضاً"| c2a["التنفيذ أخفّ"]
    pt2 -->|"الأولى فقط"| c3a["cold / warm"]
    pt2 -->|"بطيء في النصف الثاني"| c4a["حرارة ونشاط خلف"]

الشكل 16: نمط كيفيّة ظهور الفرق، أكثر من الفرق نفسه، يعطي حدساً للسبب.

احفر حتّى «لماذا أسرع» بـ ETW / WPR

حين يصغر الفرق أو يتعذّر قراءة السبب، الطريق الملكيّ التقدّم إلى أدوات عائلة ETW (Event Tracing for Windows) في Windows.

Windows Performance Recorder (WPR) من Microsoft أداة تسجيل قائمة على ETW، وهي ضمن Windows ADK. يمكن أخذ CPU و I/O و context switch و أخطاء الصفحات معاً.

في الحدّ الأدنى تقريباً كالتالي.

wpr -start CPU -filemode

REM ここでベンチを実行する

wpr -stop trace.etl

بعد الفتح في WPA، الرسوم التي تُنظَر أوّلاً محدّدة تقريباً.

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

عند الوصول إلى هذه المرحلة، لا «B أسرع بنسبة 3%» بل يمكن الحديث بسبب: «في B انخفض انتظار lock فانخفض ready time» «في A زاد فتح الملفّات فصار الإقلاع البارد بطيئاً».

flowchart TB
    accTitle: من فرق أرقام فقط إلى فرق بسبب
    accDescr: مخطّط يبيّن أنّه حين يصغر الفرق أو يتعذّر قراءة السبب، أخذ تتبّع واحد لكلّ من A و B بنفس السيناريو بـ WPR ومقارنة نفس الرسم جنباً إلى جنب في WPA يجعل الحديث ممكناً بسبب لا بنسبة مئوية أسرع.
    small2["الفرق صغير أو السبب غير مقروء"] --> tr1["أخذ تتبّع A و B بـ WPR"]
    tr1 --> cmp2["النظر إلى نفس الرسم جنباً إلى جنب في WPA"]
    cmp2 --> rsn1["يصير الحديث ممكناً بسبب"]
    cmp2 -.-> onen1["بنسخة واحدة لا يُحكَم أهو بطيء"]

الشكل 17: إن حُفر حتّى ETW، تحوّل «أسرع بنسبة كم» إلى «لماذا أسرع».

قائمة تحقّق ملخّصة في صفحة واحدة

أخيراً نضعها بشكل يمكن لصقه كما هو في دليل الإجراءات.

ثبّت

• ثبّت هدف المقارنة (commit hash / build number / Debug أم Release / شروط البناء مثل PGO / وجود السجلّ و assert)
• الحاسوب المحمول باتّصال AC
• ثبّت Power mode في تطبيق الإعدادات
• أكّدتَ Active power plan بـ powercfg /getactivescheme
• أوقفتَ الإشعارات. أوقفتَ فهرس البحث ومزامنة السحابة
• جعلتَ clean boot إن لزم
• أعدتَ التشغيل وبدأتَ بعد انتظار دقائق

نفّذ

• أدخلتَ إحماء
• قِستَ cold (الأولى) و warm (المستقرّ) منفصلتين
• بدّلتَ A / B أو شغّلتَ بترتيب عشوائيّ
• قرّرتَ العدد وشغّلتَ (المؤشّر الجدول أعلاه)

سجّل

• أبقيتَ بيانات خامّاً سطراً لكلّ تنفيذ (elapsed_ms / user_ms / kernel_ms / cycles)
• أبقيتَ AC أم DC، و Power mode (وضع الطاقة)، و GUID لـ Power plan (خطّة الطاقة)، و Windows build، و driver version
• أبقيتَ حرارة الغرفة وحالة الوضع
• كتبتَ أيضاً الشروط التي لم تُثبَّت

فسّر

• نظرتَ إلى الوسيط. لم تحكم بالمتوسّط وحده
• نظرتَ إلى الذيل بـ p95 / p99
• أكّدتَ القيمة الشاذّة بـ min / max
• خمّنتَ السبب بجمع wall-clock / CPU time / cycle
• حفرتَ حتّى ETW / WPR حين صغر الفرق

الخلاصة

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

• ثبّت AC / Power mode (وضع الطاقة) / Power plan (خطّة الطاقة) وسجّلها
• افصل cold و warm
• بدّل A / B
• انظر إلى الوسيط والتوزيع
• clean boot إن لزم
• إن صغر الفرق فاحفر السبب بـ ETW / WPR

وأهمّ شيء كتابة ما ثبّتَّ وما لم تثبّت مع النتيجة. القياس مقارنة سرعة وفي الوقت نفسه تسجيل لشروط التجربة.

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

flowchart TB
    accTitle: تسجيل الشروط يحسم قيمة النتيجة
    accDescr: مخطّط يبيّن أنّ تقرير تسريع بلا شروط مكتوبة يبقى الرقم وحده ولا تبقى وسيلة إعادة الإنتاج، وأنّ كتابة الشروط كما ينبغي تعطي قيمة حتّى إن صغر الفرق، فالقياس تسجيل لشروط التجربة أيضاً.
    norec1["تقرير لا يكتب الشروط"] --> onlyn1["يبقى الرقم وحده"]
    onlyn1 --> norep1["لا يستطيع غيره التحقّق"]
    rec3["تقرير كتب الشروط"] --> rep1["تبقى وسيلة إعادة الإنتاج"]
    rep1 --> worth1["قيمة حتّى إن صغر الفرق"]

الشكل 18: قيمة القياس تسكن لا في الرقم بل في تسجيل ما ثُبِّت وما لم يُثبَّت.

روابط مرجعية

• 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. أيّ رسم يُنظَر لأيّ غرض.
• Microsoft Learn, Set the Default Power Plan. مثال خرج powercfg -LIST.

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

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

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

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

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

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

ما الأسباب الرئيسيّة لتذبذب نتائج القياس على Windows؟

ثمّة عوامل متعدّدة الطبقات: Power mode (وضع الطاقة) و Power plan (خطّة الطاقة)، والحرارة، وتحديثات الخلفيّة، وفهرس البحث، ومسح الفيروسات، والأولويّة والارتباط، وترتيب التنفيذ، وحالة الذاكرة المؤقّتة. حتّى على نفس جهاز Windows، إن لم تتوافق هذه الشروط صار الأمر تجربة أخرى فعليّاً. على الحواسيب المحمولة خصوصاً يتغيّر السلوك كثيراً بين الاتّصال بـ AC والعمل على البطاريّة، لذا قارن حتماً مع اتّصال AC وسجّل الشروط.

ما الفرق بين Power mode (وضع الطاقة) و Power plan (خطّة الطاقة)؟

Power mode تبديل Best power efficiency و Balanced و Best performance الذي تختاره في Power & battery في تطبيق الإعدادات، ويؤثّر في إعدادات الطاقة خلفه وفي سلوك PPM (Processor Power Management). Power plan خطط طاقة تقليديّة مثل Balanced و High performance يمكن تأكيدها بـ powercfg. لأنّ الاثنين موجودان على Windows، يلزم تسجيل ثلاث على الأقلّ مع نتيجة القياس: AC أم بطاريّة، و Power mode، و Active power plan.

إن لم تظهر خطّة الطاقة High performance، أهذا عطل؟

غالباً ليس عطلاً. وثائق Microsoft تقول إنّ الأجهزة الداعمة لـ Modern Standby لا يُسمَح فيها إلا بـ Balanced أو خطط مشتقّة من Balanced. أي أنّ غياب High performance بحكم تصميم ذلك الطراز أمر وارد. وإن تعذّر تغيير واجهة Power mode فقد تكون خطّة مخصّصة (custom power plan) مختارة، فالأسرع تجربة اختيار Balanced أوّلاً.

بأيّ ترتيب ينبغي تنفيذ مقارنة سرعة الإصدارين A و B؟

تجنّب تشغيل A كلّه أوّلاً ثمّ تشغيل B. لأنّ انحياز الحرارة والذاكرة المؤقّتة ونشاط الخلفيّة يركب على طرف واحد. بدّل A B A B أو نفّذ بترتيب عشوائيّ مولَّد مسبقاً. وافصل أيضاً المرّة الأولى الباردة عن الحالة المستقرّة بعد الإحماء، وانظر لا إلى المتوسّط وحده بل إلى الوسيط و p95 والحدّ الأدنى والحدّ الأقصى، فتمنع قيمة شاذّة من سحب النتيجة.

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

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

غو كومورا

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

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