كيف تقيّم Hone تحسينات الأداء

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

هذا لا يكفي لدى Hone.

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

الخلاصة

يحتاج كل تحسين من Hone إلى:

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

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

على الشاشات الصغيرة، انقل التركيز إلى الشكل واستخدم مفاتيح الأسهم أو اسحب للتنقل أفقيًا.

1. ابدأ بالمشكلة

نبدأ بالمشكلات المعتادة التي قد يلاحظها اللاعب، ومنها:

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

إذا لم نستطع وصف المشكلة، نرفض التعديل تلقائيًا.

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

2. افهم ما يغيّره التعديل

يحتاج كل تحسين إلى شرح مباشر.

ينبغي أن نستطيع الإجابة عن الأسئلة التالية:

• أي جزء من Windows يتأثر به؟
• ما السلوك الذي يتغير بعد تطبيقه؟
• لماذا يمكن أن يؤثر ذلك في اللعب؟
• ما الأنظمة المرجح أن تستفيد منه؟

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

لا يثبت ذلك أن التعديل مفيد دائمًا، لكنه يمنحنا آلية يمكن اختبارها.

إذا لم نستطع شرح الآلية، نتعامل مع التعديل على أنه تخمين.

3. حدّد المخاطر

نبحث عما قد يحدث بصورة خاطئة قبل أن نبحث عن مكسب في الأداء.

بحسب التغيير، قد يؤثر التحسين في:

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

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

لا نرفض التعديل الأعلى خطورة تلقائيًا، لكنه يحتاج إلى أدلة أقوى، واستهداف أضيق، وطريقة موثوقة للتراجع.

إذا لم نستطع التراجع عن تغيير بأمان، فلا نتعامل معه باستخفاف.

4. عرّف معنى النجاح

لا يهدف كل تحسين إلى زيادة متوسط FPS.

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

نختار الاختبار بحسب الادعاء:

• FPS والسلاسة: متوسط FPS، وأدنى 1% وأدنى 0.1%، وأزمنة الإطارات، والتقطّع
• زمن الاستجابة: زمن استجابة الكمبيوتر المقاس، وتوقيت برامج التشغيل، وسلوك المقاطعات، أو جدولة المعالج
• التخزين: زمن استجابة القراءة والكتابة، ووقت الاستجابة، والتوقفات أثناء تحميل الأصول
• الشبكة: Ping، والتذبذب، وسلوك الحزم، وتضخم المخزن المؤقت

هذا مهم لأن القياس الخاطئ قد يجعل نتيجة ضعيفة تبدو ناجحة.

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

على الشاشات الصغيرة، انقل التركيز إلى الشكل واستخدم مفاتيح الأسهم أو اسحب للتنقل أفقيًا.

5. أجرِ اختبارات مضبوطة

أداء الكمبيوتر متقلب.

قد تتغير النتائج بسبب تجميع المظللات، أو مهام Windows، أو درجات الحرارة، أو تطبيقات الخلفية، أو اختلاف الخرائط، أو ظروف الخادم، أو حتى اتجاه نظر اللاعب أثناء الاختبار.

نتحكم في أكبر عدد ممكن من العوامل:

• الكمبيوتر والعتاد نفسيهما
• اللعبة والخريطة والمشهد والمسار أو الإعادة نفسها
• إعدادات الرسوميات نفسها
• إصدارات Windows وبرامج التشغيل نفسها
• خطة الطاقة نفسها
• تطبيقات الخلفية نفسها
• طريقة الالتقاط ومدة الاختبار نفسيهما
• حد FPS وإعدادات المزامنة نفسيهما
• شروط إعادة التشغيل نفسها

نختبر كذلك تغييرًا واحدًا في كل مرة. فإذا فُعّلت خمسة تعديلات معًا، فلن نعرف أيها أفاد أو تسبب في مشكلة.

لا تكفي نتيجة جيدة واحدة.

لكل جهاز كمبيوتر، نجري الاختبار المرجعي من 3 إلى 5 مرات قبل تطبيق التعديل. ثم نطبق التعديل مرة واحدة، ونعيد التشغيل عند الحاجة، ونجري الاختبار نفسه من 3 إلى 5 مرات بعد التطبيق.

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

قبل مقارنة النتائج، ننظر في مقدار اختلاف الجولات المرجعية بعضها عن بعض. لا نعد التعديل تحسينًا إلا عندما تتفوق النتائج اللاحقة على التباين المرجعي الطبيعي ويظهر التغيير باستمرار في عدة جولات.

إذا كانت النتائج قبل التطبيق وبعده متشابهة أكثر من اللازم، تكون الخلاصة «لا يوجد فرق قابل للقياس».

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

على الشاشات الصغيرة، انقل التركيز إلى الشكل واستخدم مفاتيح الأسهم أو اسحب للتنقل أفقيًا.

6. قارن النتيجة بالمخاطر

لا يستحق كل تحسن قابل للقياس أن يُنشر.

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

نراجع النتيجة كاملة:

• ما حجم التحسن؟
• هل تكرر؟
• هل تحسن انتظام أزمنة الإطارات؟
• هل تحسن زمن الاستجابة؟
• هل ساء مقياس آخر؟
• هل ظل النظام مستقرًا؟
• هل يمكن التراجع عن التغيير؟
• هل يفيد عتادًا أو ألعابًا محددة فقط؟

لا يقتصر السؤال على ما إذا كان رقم قد ارتفع. يجب أن تبرر الفائدة التغيير.

7. حدّد أين يفيد وأين لا يفيد

ترتبط معظم التحسينات بشروط معينة.

قد يفيد التعديل عندما:

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

لا يجعل ذلك التعديل ضعيفًا.

نفضّل تقديم ادعاء محدد يمكننا دعمه على أن نَعِد الجميع بزيادة FPS.

8. احتفظ به أو غيّره أو ارفضه

ينتهي كل تحسين إلى واحد من ثلاثة قرارات.

الاحتفاظ

نحتفظ به عندما:

• تكون الآلية واضحة
• يتحسن المقياس المستهدف
• تتكرر النتيجة
• تكون المخاطر مبررة
• يكون التغيير قابلًا للتراجع
• نعرف أين ينبغي استخدامه

لا تعني «المخاطر المقبولة» انعدام المخاطر، بل تعني أن الضرر المحتمل محدود ومفهوم ويمكن التعافي منه.

التغيير

تكون الفكرة سليمة أحيانًا، لكن التنفيذ لا يكون جاهزًا.

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

لا تعني نتيجة قياس إيجابية أننا سننشر التعديل تلقائيًا.

الرفض

نرفض التعديل عندما:

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

رفض تعديل جزء دائم من العملية، أما نشر تعديل غير مثبت فهو الفشل.

مثال: تخصيص الأجهزة

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

وبدلًا من التسرع في الادعاء بأن «هذا التعديل يزيد FPS»، توصلنا إلى النتيجة التالية:

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

على الشاشات الصغيرة، انقل التركيز إلى الشكل واستخدم مفاتيح الأسهم أو اسحب للتنقل أفقيًا.

ما لا تدّعيه Hone

لا تدّعي Hone أن كل تحسين يفيد كل جهاز كمبيوتر.

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

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

هذا هو المعيار الذي نريد أن يستوفيه كل تحسين من Hone.