مقارنة البداية الباردة بالبداية الدافئة

Question

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

يبدو أن معظم الفرق (إن لم يكن كله) يأتي من تحميل مكتبات الارتباط الحيوي (DLL)، عندما تكون مكتبات الارتباط الحيوي (DLL) في صفحات الذاكرة المخزنة مؤقتًا يتم تحميلها بشكل أسرع بكثير.لقد حاولنا استخدام ClearMem لمحاكاة إعادة التشغيل (نظرًا لأنها تستغرق وقتًا أقل بكثير من إعادة التشغيل فعليًا) وحصلت على نتائج مختلطة، في بعض الأجهزة بدا أنها تحاكي إعادة التشغيل بشكل متسق للغاية وفي بعضها الآخر لا.

وخلاصة أسئلتي هي:

1. هل واجهت اختلافات في وقت الإطلاق بين البدايات الباردة والدافئة؟
2. كيف تعاملت مع مثل هذه الاختلافات؟
3. هل تعرف طريقة لمحاكاة إعادة التشغيل بشكل موثوق؟

يحرر:

توضيحات للتعليقات:

• التطبيق في الغالب هو C++ أصلي مع بعض .NET (أول تجميع .NET يتم تحميله يدفع مقابل CLR).
• نحن نتطلع إلى تحسين وقت التحميل، ومن الواضح أننا قمنا بنصيبنا من التوصيف وقمنا بتحسين نقاط الاتصال في التعليمات البرمجية الخاصة بنا.

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

Answer 1

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

ربما حتى لصق معلومات التوقيت الأساسية في الكود والكتابة في ملف السجل وفحص الملفات عند البداية الباردة/الدافئة سيساعد في تحديد أين التطبيق يقضي الوقت.

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

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

لا أعرف أي أدوات مرتجلة لمسح ذاكرة التخزين المؤقت للقرص/نظام الملفات، ولكن يمكنك كتابة تطبيق سريع لقراءة مجموعة من الملفات غير ذات الصلة من القرص للتسبب في تحميل ذاكرة التخزين المؤقت لنظام الملفات/القرص بمعلومات مختلفة.

Answer 2

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

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

Answer 3

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

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

Answer 4

@مورتن كريستيانسن قال:

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

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

Answer 5

إحدى الطرق الناجحة لتسريع بدء تشغيل التطبيق هي تحويل ملفات DLL إلى التحميل المؤجل.يعد هذا تغييرًا منخفض التكلفة (بعض التلاعب بإعدادات المشروع) ولكنه يمكن أن يجعل بدء التشغيل أسرع بشكل ملحوظ.بعد ذلك، قم بتشغيلdependent.exe في وضع التوصيف لمعرفة ملفات DLL التي يتم تحميلها أثناء بدء التشغيل على أي حال، وإرجاع التحميل المؤجل عليها.تذكر أنه يمكنك أيضًا تأخير تحميل معظم ملفات DLL التي تحتاجها لنظام التشغيل Windows.

Answer 6

من الأساليب الفعالة جدًا لتحسين وقت التشغيل البارد للتطبيق تحسين ترتيب ارتباطات الوظائف.

يتيح لك رابط Visual Studio تمرير ملف يسرد كافة الوظائف الموجودة في الوحدة النمطية المرتبطة (أو بعضها فقط - ليس من الضروري أن تكون جميعها)، وسيقوم الرابط بوضع هذه الوظائف بجوار بعضها البعض في ذاكرة.

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

يمكن أن يكون تحسين تطبيقك بحيث يتم جمع كل هذه الوظائف معًا بمثابة فوز كبير.

تحقق من التحسين الموجه لملف التعريف في Visual Studio 2005 أو الإصدارات الأحدث.أحد الأشياء التي تقدمها لك PGO هو طلب الارتباط الوظيفي.

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

هناك المزيد من المعلومات حول PGO هنا:

http://msdn.microsoft.com/en-us/library/e7k32f4k.aspx

Answer 7

كبديل لقائمة ترتيب الوظائف، ما عليك سوى تجميع التعليمات البرمجية التي سيتم استدعاؤها ضمن نفس الأقسام:

#pragma code_seg(".startUp")
 //...
#pragma code_seg

#pragma data_seg(".startUp")
 //...
#pragma data_seg

يجب أن يكون من السهل الحفاظ عليه مع تغير التعليمات البرمجية الخاصة بك، ولكن له نفس فائدة قائمة ترتيب الوظائف.

لست متأكدًا مما إذا كانت قائمة ترتيب الوظائف يمكنها تحديد المتغيرات العامة أيضًا، ولكن استخدام #pragma data_seg سيعمل ببساطة.

Answer 8

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

ملاحظة أخرى، هي أنه من المفترض أن يكون .NET 3.5SP1 قد تحسن كثيرًا في سرعة البدء البارد، على الرغم من أنني لا أستطيع تحديد مقدار ذلك.

Answer 9

يمكن أن يكون NIC (بطاقات LAN) وأن تطبيقك يعتمد على بعض الخدمات الأخرى التي تتطلب من الشبكة الخروج.لذا فإن تحديد ملف تعريف تطبيقك وحده قد لا يخبرك بذلك تمامًا، ولكن يجب عليك فحص تبعيات تطبيقك.

Answer 10

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