تحسين البرامج والتطبيقات

السلام عليكم ورحمه الله وبركاته قرأت عدة مرات حول هذا الامر فى الاسمبلي وخاصة فى الجزء الاخير من كتاب Art Of Assmbley وترجمة بعض المحتويات

لذا أود اطلاعكم علي بعض المعلومات والتفاصيل حوله

كيف يمكنني أن أجد الكود (التعليمات) الذي يسبب بطئ فى برنامجي (تطبيقي) ؟

يمكن ان نلخص ان الحل الآمثل فى ذلك هو ايجاد التعليمات التي يقضي التطبيق فى تنفيذها المدة الاطول فى البرنامج ومحاولة عمل Optimization لها

وهناك 4 أساليب (تقنيات) يستخدما المبرمجين فى حل تلك المعضلة ويستخدموها فى ايجاد "hotspots" وهو الاماكن التي يقضي عندها التطبيق معظم الوقت

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

الاسلوب الثاني والذي يستخدمه الكثيرين هو تحسين أداء كل شئ بل وحتي يمكن ان تصل الي حد اعادة كتابة وتحسين كل التعليمات

الاسلوب الثالث وهو أكثر منطقية هو تحليل التطبيق أو البرنامج وهو فى وجهة نظري أكثر عقلانية من سابقيه

الاسلوب الرابع هو استخدام profiler أو اي software monitoring tool أخر ليقوم بالتأكد من أداء بعض الاجزء المعينة فى التطبيق وبعد تحديد hotspot معينة فان المبرمج يحاول ان يحلل ويحسن ذلك الجزء او الاجزاء من البرنامج

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

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

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

اما الاسلوب الثاني والذي ذكرته سابقا وهو محاولة تحسين كل شئ (optimize everything) وبالتأكيد فان هذا الاسلوب لا يصلح عموما مع البرامج الضخمة والمعقدة لكن بالنسبة للاجزاء الصغيرة من التعليمات فانه يعمل جيدا

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

وذلك لانك قد قمت بتحسين أداء كل تعليمات ومهمات برنامجك

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

بالنسبة للجزء النظري فان هذا الاسلوب هو الافضل

أما اذا نظرنا الي الواقع العملي فان الانسان بشكل عام كل يوم علي نفوره من عملية التحليل الي قدر الامكان يحاول الابتعاد عنه (لاحظ انني هنا اتكلم عن واقع وبشكل عام وليس الاصح او الاستثناءات او الجزء المحترف من المبرمجين )

وفى الواقع ان عملية التحليل ليست دائما صحيحة فهي تعتمد على خبرة الشخص وايضا التوقع قد يكون خاطئ والعامل البشري داخل فى الامر وعملية التحليل تستغرق مهماتها وقتا كبيرا للانتهاء منها

وبالرغم من مشاكل عملية التحليل فانك يجب ان تستخدمها كأسلوب أول للتعامل الواقعي مع تحسين أداء برنامجك فان عادة معظم البرامج تستهلك الوقت الاكبر لها فى تنفيذ ( Loops ,function calls ...الخ )

لذا يجب عليك التعامل بدقة اكبر مع تلك النقاط فيجب عليك مراجعة Loop body وخاصة nested Loops و تحديد كل recursive function calls المتواجدة فى برنامجك فالفرص كبيرة فى ان برنامجك يقضي الوقت الاطول فى تنفيذ تلك المهمات فى تلك المناطق من تعليمات برنامجك لذا فان تلك Spots اساسي ان تنظر اليها وتضعها فى اعتبارك عند عملية الoptimization

وبالرغم من ان اسلوب التحليل يعطي طريقة جيدة لمعرفة Slow Code فان عملية التحليل ل Program نفسها بطيئة وهي عملية مملة فى معظم الاحيان ومن الممكن جدا الخطأ اثناء ادائها وخاصة فى النقطة الخاصة ب recursive function calls (عن تجربة شخصية)

وكذلك فان تحديد الnested Loops التي التي تستهلك الوقت أمرا صعبا وليس سهلا على الاطلاق

فى النهاية فان النصيحة التي دائما ما يمكن تقديمها هي انه فى عملية الoptimization لبرنامجك فضع أسلوب analysis دائما كخيار أول

ولآن معظم المبرمجين لا يجيدون بشكل كامل تحليل برمجياتهم للعثور علي hotspots فان الاتجاه الان يكون نحو أتمتة تلك العملية أي جعلها تحدث بشكل تلقائي ومصطلح الاتمتة هو التعريب الذي وجدته ل(automation)

وهذا الامر يتم عن طريق profiler حيث يقوم بتلك العملية عنك :wink: والprofiler هو برنامج واداة صعيرة تقيس الوقت الذي يستهلكه الجزء المحدد من تعليمات برنامجك وبالطبع فانك ستريد استخدام ذلك الاسلوب باستخدام profiler وهو ما قدمته لنا شركات عديدة فانك تحتاج الي profiler Program وهناك شركات مثل Borland و Microsoft تقدم لنا العديد من ادوات وبرمجيات profiler لمساعدة المطورين والمبرمجين مع optimization tools الاخري

وهناك نوعان منه

• Flat profiler
  
• Call-graph profiler
  

وتلك بعضها

CLR Profiler

gprof

ويتواجد ضمن JVMTI وهي مجموعة أدوات خاصة بلغة جافا profiler

المصدر كتاب Art Of Assmbley وبعض المقالات التي كنت قرأتها سابقا وبعض الخبرات فى هذا الامر

والله ولي التوفيق