كيف تقارن إصدارات البرامج على Windows دون قياس الشيء الخطأ

إن أردت مقارنة الإصدار A بالإصدار B من برنامج على Windows، فإنّ أسهل خطأ هو أيضاً الأكثر شيوعاً:

تُشغِّل كلّ إصدار مرّة واحدة على الجهاز نفسه، فترى فرقاً مقداره 8%، ثمّ تعتبر ذلك نتيجة.

قد يأتي هذا الفرق البالغ 8% فعلاً من الشيفرة.
لكنّه على Windows قد يأتي أيضاً من power mode، أو power plan، أو الحالة الحراريّة، أو تحديثات الخلفيّة، أو الفهرسة، أو فحص antivirus، أو CPU affinity، أو ترتيب التشغيل، أو حالة الـ cache. هذه قصّة benchmarking عاديّة جدّاً.

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

النسخة المختصرة

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

1. حدِّد ما الذي تقارنه فعلاً قبل أن تبدأ
   • «هل صارت الشيفرة أسرع؟» و«هل تجربة المستخدم تشعر بأنّها أسرع؟» ليستا الـ benchmark نفسه.
2. سجِّل power mode و power plan بشكل منفصل
   • إن خلطتهما معاً، فقد يتحوّل الـ benchmark بهدوء إلى مقارنة لسلوك طاقة Windows بدلاً من سلوك البرنامج.
3. عامِل التشغيلات الباردة وتشغيلات الحالة المستقرّة كأشياء مختلفة
   • سلوك التشغيل الأوّل والسلوك بعد الإحماء يرويان قصصاً مختلفة في الغالب.
4. بدِّل بين الإصدارين بدلاً من تشغيل كلّ A ثمّ كلّ B
   • وإلّا فإنّ الحرارة ونشاط الخلفيّة قد يحيّزان جانباً واحداً.
5. انظر إلى الوسطاء (medians) والتشتّت، لا إلى المتوسّطات فقط
   • يكفي outlier واحد ليشوّه الصورة بأكملها.
6. إن كان الفرق صغيراً، فانتقل إلى ETW / WPR
   • عند تلك النقطة، عادةً ما لا يكون التخمين بالشعور كافياً.

أوّلاً: حدِّد نوع المقارنة

تبدو «مقارنة الأداء» مفهوماً واحداً، لكنّها عادةً تعني واحداً من شيئين مختلفين جدّاً.

1. benchmark لفرق الشيفرة

هذه هي الحالة التي تريد فيها أن تعرف ما إذا كان تغيير في التنفيذ قد جعل البرنامج فعلاً أخفّ أو أسرع:

• تغييرات الخوارزميّات
• تغييرات بنى البيانات
• تغييرات تحسينات المترجم
• ترقيات runtime

هنا، الخطوة الصحيحة هي تقليل ضوضاء البيئة بقوّة:

• جلسة benchmark مخصّصة
• إعدادات طاقة ثابتة
• إيقاف الإشعارات
• تقليل الفهرسة أو المزامنة
• clean boot عند الضرورة

2. مقارنة تجربة مستخدم حقيقيّ

أحياناً لا يكون السؤال «هل صارت الشيفرة أسرع في المختبر؟» بل:

«هل يبدو الإصدار الأحدث أسرع في الاستخدام الاعتياديّ على Windows؟»

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

اخلط هذين النوعين من الـ benchmark، وستبدأ الاستنتاجات بالالتواء:

• أسرع بنسبة 12% في المختبر، لكن بلا معنى في الاستخدام الفعليّ
• لا تغيّر في زمن CPU، لكن تجربة طرف-إلى-طرف أسرع بشكل ملحوظ

كلتا الحالتين نتيجتان طبيعيّتان حين لا يكون هدف الـ benchmark معلناً بوضوح.

ما الذي يسبّب التغاير عادةً على Windows

قبل محاولة التحكّم بالبيئة، من المفيد تسمية مصادر الانحراف.

الخلاصة العمليّة بسيطة:

«جهاز Windows ذاته» ليس الشيء نفسه «شروط benchmark ذاتها».

power mode و power plan ليسا الشيء نفسه

هذا أحد أسهل الأخطاء التي تُرتكب في benchmarking على Windows.

هناك إعداد Power mode الحديث من تطبيق إعدادات Windows، وهناك Power plan التقليديّ الذي يظهر عبر powercfg.

هما مرتبطان، لكنّهما ليسا الشيء نفسه.
إن عاملتهما كزرّ واحد، فقد يصبح الـ benchmark فوضويّاً بسرعة كبيرة.

كحدّ أدنى، سجِّل هذه الأشياء الثلاثة:

• ما إذا كان الجهاز على AC أو battery
• أيّ Power mode كان مختاراً
• أيّ Power plan كان نشطاً

إن لم تتضمّن نتيجة benchmark هذه الأشياء، يصبح من الأصعب بكثير تفسيرها لاحقاً.

قواعد طاقة عمليّة

1. استخدم AC على اللابتوبات
   • اختبار البطّاريّة عالم benchmark مختلف.
2. ثبِّت Power mode
   • بالنسبة لـ benchmarking مركَّز على الشيفرة، فإنّ Best performance نقطة بداية معقولة.
3. سجِّل الـ power plan النشط

powercfg /list
powercfg /getactivescheme

1. بدِّل الخطط عمداً عند الحاجة

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

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

حين لا يكون «High performance» متاحاً

هذا لا يعني تلقائيّاً أنّ الجهاز معطوب.

على الأجهزة المبنيّة حول Modern Standby، قد يسمح Windows فعليّاً فقط بـ Balanced أو الخطط المشتقّة منه.
لذا فإنّ «High performance مفقود» قد يكون خاصيّة تصميميّة للنظام، لا خطأ.

قلِّل ضوضاء الخلفيّة قبل أن تقلِّل مصداقيّتك

Windows لا يجلس فعلاً دون أن يفعل شيئاً.
هذا عادةً جيّد للمستخدم، لكنّه غير ملائم حين تريد benchmark مضبوطاً.

أعِد التشغيل، ثمّ انتظر

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

استخدم clean boot حين تكون المقارنة جدّيّة

إن كان الفرق صغيراً بما يكفي للجدال عليه، فإنّ clean boot يستحقّ الاعتبار في الغالب.
هو أنسب بكثير لـ benchmarking فرق الشيفرة في بيئة شبيهة بالمختبر منه لـ benchmarking تجربة المستخدم.

أسكِت الإشعارات

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

اكبح الفهرسة والمزامنة حين يكون ذلك مهمّاً

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

خطوات التنظيف النموذجيّة هي:

• استبعاد دليل الـ benchmark من الفهرسة
• إيقاف OneDrive أو Dropbox أو أدوات المزامنة المماثلة مؤقّتاً
• إغلاق المتصفّحات وأدوات المحادثة

مع Defender، حدِّد القاعدة بدلاً من التخمين

ليست الإجابة الصحيحة تلقائيّاً «عطِّل Defender».

إن أزعج Defender الـ benchmark بشكل ماديّ، فاستخدم استثناءات محصورة بعناية لدليل الـ benchmark أو العمليّة بالضبط، وسجِّل هذه الحقيقة مع النتيجة.
وإلّا فقد تنتهي إلى benchmarking لبيئة لم تعد تمثّل استخدام Windows الحقيقيّ.

إن لم تتحكّم بالحالة الحراريّة، فقد تكون فقط تقيس الحرارة

السيليكون البارد والسيليكون المُحَمَّى ليسا الجهاز نفسه عمليّاً.
هذا واضح بشكل خاصّ على اللابتوبات والـ mini PCs وأجهزة سطح المكتب المدمجة.

القواعد المفيدة هي:

• إبقاء حرارة الغرفة ثابتة قدر الإمكان عمليّاً
• إبقاء وضع اللابتوب متّسقاً
• إبقاء إعداد الـ dock والشاشة ومحوّل الطاقة متّسقاً
• تجنّب العمل الثقيل قبل الـ benchmark مباشرةً
• فصل قياسات التشغيل الأوّل عن قياسات الحالة المستقرّة

بدِّل ترتيب التنفيذ

تشغيل A عشر مرّات ثمّ B عشر مرّات هو دعوة للتحيّز الحراريّ.

الأنماط الأفضل هي:

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

النقطة هي تجنّب أن يرى أحد الإصدارين دائماً الجهاز الأبرد ويرى الآخر دائماً الأدفأ.

معنى «أسرع» يعتمد على ما تقيسه

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

1. Wall-clock time

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

على Windows، الـ primitive الأساسيّ الصحيح هو QueryPerformanceCounter (QPC).
في الـ managed code، يعني ذلك عادةً Stopwatch.

2. CPU time

يأتي هذا من GetProcessTimes ويخبرك كم استهلكت العمليّة فعلاً من زمن CPU في user mode و kernel mode.

هو مفيد حين تريد معرفة ما إذا كان التنفيذ نفسه قد صار أخفّ، حتّى لو تأثّر wall-clock time بالانتظار أو I/O أو الجدولة.

3. Cycle count

يعطي QueryProcessCycleTime عدد دورات CPU على مستوى العمليّة.

هذه طريقة مفيدة أخرى لرؤية ما إذا كان عمل CPU الفعليّ قد تغيّر، حتّى حين يتأثّر زمن الطرف-إلى-الطرف بعوامل أخرى.

قاعدة عمليّة

إن كان عليك اختيار واحد، فاختر wall-clock time.
إن أردت فهم الفرق بدلاً من مجرّد الإبلاغ عنه، فإنّ wall-clock مع CPU time أقوى بكثير بالفعل.

priority و affinity و NUMA أدوات الملاذ الأخير

هذه الإعدادات قد تكون مهمّة.
يمكنها أيضاً إنشاء benchmark لم يعد يشبه تنفيذ Windows الحقيقيّ.

ابدأ بسلوك المجدول الافتراضيّ

إن كان فرق ذو معنى مرئيّاً تحت التنفيذ الاعتياديّ، فإنّ تلك النتيجة لها قيمة بالفعل.
القفز مباشرةً إلى /high أو /affinity يمكن أن ينشئ شرط benchmark لن يشغّله المستخدمون أبداً فعلاً.

إن استخدمتها، فكُن صريحاً حول السبب

• /high: تقليل التداخل من العمليّات الأخرى
• /affinity: تثبيت موضع CPU من أجل الاتّساق
• التحكّم بـ NUMA: محاذاة الأنظمة الكبيرة متعدّدة المقابس أو ذات الأنوية العالية بعناية أكبر

يمكن استخدام start على Windows هكذا:

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

تجنّب /realtime

/realtime موجود، لكنّه الأداة الخطأ للـ benchmarking الاعتياديّ.
هو أفضل بكثير في إنشاء مشاكل على مستوى النظام منه في إنشاء قياسات موثوقة.

إجراء benchmark عمليّ

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

تدفّق المقارنة بأسلوب المختبر

1. ثبِّت القطع المقارَنة (artifacts)
   • commit hash / build number
   • إصدار المترجم والـ runtime
   • Debug / Release
   • إعدادات التسجيل والـ assertions والـ trace
2. ثبِّت ظروف الجهاز
   • Windows build
   • إصدار BIOS / UEFI
   • إصدارات الـ drivers
   • طاقة AC
   • حرارة الغرفة والوضع
3. ثبِّت ظروف الطاقة
   • اختر Power mode
   • سجِّل الـ power plan النشط

4. أعِد التشغيل

5. انتظر بضع دقائق

6. استخدم clean boot عند الضرورة

7. ضمِّن تشغيلات إحماء (warm-up)
   • JIT وتحميل DLL وإنشاء الـ cache يجب ألّا تختلط مع تنفيذ الحالة المستقرّة

8. بدِّل بين A و B

9. شغِّل عيّنات كافية
   • الـ benchmarks القصيرة: حوالى 30+ تشغيلاً
   • المتوسّطة: 10 إلى 20 تشغيلاً
   • الطويلة: حتّى 5 إلى 10 تشغيلات قد تنفع، لكن بدِّل بين الإصدارين رغم ذلك

10. احتفظ بالوسيط والـ min والـ max و p95

11. احفظ البيانات الخام

12. إن كان الفرق صغيراً، فالتقط ETW / WPR

ما الذي يجب تسجيله مع النتيجة

كحدّ أدنى، يساعد الاحتفاظ بشيء مثل:

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

الـ benchmarking ليس فقط حول القياس بسرعة.
هو أيضاً حول القدرة على شرح النتيجة لاحقاً.

انظر إلى الوسطاء والتوزيعات، لا إلى المتوسّطات فقط

المتوسّطات سهلة القراءة وسهلة الكسر.

فحص Defender واحد، أو إشعار واحد، أو عمليّة واحدة لا علاقة لها وتُثقل SSD، يمكن أن يجرّ المتوسّط بعيداً عمّا تقوله بقيّة البيانات فعلاً.

العروض المفيدة تشمل:

• الوسيط (median): عادةً أوّل ما يُوثق به
• p95 / p99: مفيدة للسلوك الذيليّ (tail)
• min / max: تساعد في إظهار قبح الـ outliers
• box plots أو scatter plots: مفيدة حين تكون الفروق صغيرة

إن كان التحسّن 10%، فعادةً ما يكون مرئيّاً.
إن كان من 1 إلى 3%، فإنّ شكل التوزيع أهمّ بكثير.

كيف تقرأ النتيجة

يصبح التفسير أوضح حين تجمع المقاييس.

يتحسّن wall-clock، لكن CPU time لا

قد يشير ذلك إلى تحسّن في I/O أو الانتظار أو سلوك الـ cache أو الجدولة، بدلاً من تكلفة الحساب الخام.

يتحسّن كلّ من CPU time و cycle count

هذا مؤشّر قويّ على أنّ التنفيذ نفسه صار أخفّ.

التشغيل الأوّل فقط مختلف

فكِّر في سلوك cold-versus-warm:

• بدء التشغيل
• التهيئة (initialization)
• إنشاء الـ cache
• JIT

التشغيلات اللاحقة تسوء

فكِّر في:

• thermal throttling
• ضغط الذاكرة
• عمل الخلفيّة

عندما يصبح من الصعب شرح الفرق من الأرقام عالية المستوى وحدها، يحين وقت الانتقال إلى ETW / WPR.

استخدم ETW / WPR حين تحتاج إلى السبب، لا إلى الرقم فقط

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

Windows Performance Recorder (WPR)، المضمَّن في Windows ADK، يستطيع التقاط:

• نشاط CPU
• I/O
• context switches
• page faults

التدفّق الأدنى يبدو هكذا:

wpr -start CPU -filemode

REM شغّل الـ benchmark هنا

wpr -stop trace.etl

عندما تحلّل الـ trace في WPA، يمكن للمحادثة أن تنتقل من:

«الإصدار B أسرع بنحو 3%»

إلى شيء أكثر فائدة بكثير، مثل:

«قلّل الإصدار B زمن ready time بتخفيض lock contention»

أو:

«يقوم الإصدار A بفتح ملفّات إضافيّة ويخسر زمناً أثناء cold start»

هنا يبدأ الضباب بالانقشاع.

الخلاصة

على Windows، الـ benchmarking الموثوق بين إصدار وآخر ليس عادةً عن حيل ذكيّة.
هو عن مجموعة صغيرة من العادات المملّة التي تجعل النتيجة قابلة للإعادة:

• ثبِّت وسجِّل AC / power mode / power plan
• افصل السلوك البارد عن السلوك الدافئ
• بدِّل بين A و B
• انظر إلى الوسطاء والتشتّت
• استخدم clean boot حين تكون المقارنة حسّاسة
• استخدم ETW / WPR حين يكون الفرق صغيراً والسبب مهمّاً

أهمّ عادة منفردة هي أن تكتب ما الذي ثبَّته وما الذي لم تثبِّته.

نتيجة benchmark ليست فقط ادّعاء سرعة.
هي أيضاً سجلّ للظروف التجريبيّة.

تقرير تحسين بلا ظروف قد يكون مسلّياً، لكنّه ليس موثوقاً جدّاً.
نتيجة موثَّقة بعناية لها قيمة حتّى عندما يكون الفرق صغيراً.

مراجع

• 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

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

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

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

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

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

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

غو كومورا

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

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