books improvement levels
If you do not find what you're looking for, you can use more accurate words.
مستويات التحسين (Info)
يمكن أن تحدث عملية التحسين في عدد من المستويات. عادةً ما تكون المستويات العليا لها التأثير الأقوى ويصعب تغييرها في وقت لاحق في المشروع، متطلباً تغييرات جذرية أو إعادة صياغة كاملة إذا أردت تغييرها. وهكذا، يمكن لعملية التحسين أن تستأنف عادةً من خلال التنقية من أعلى إلى أسفل، محققاً مكاسب أولية أكبر بعمل أقل ومكاسب لاحقة أقل متطلبة عمل أكثر. ومع هذا، يعتمد الأداء الكلي في بعض الحالات على أداء أجزاء صغيرة المستوى من البرنامج وتغييرات صغيرة في المرحلة الأخيرة أو اعتبارات مبدئية لتفاصيل صغيرة المستوى يمكن أن تحدث تأثير هائل. عادةً تَعطى بعض الاعتبارات للكفاءة خلال المشروع- بالرغم من أن ذلك يتغير كثيراً- لكن غالباً ما تعتبر التحسينات الكبرى من مرحلة التدقيق التي تتم مؤخراً. يوجد عادة دوائر لتحسين المشروعات طويلة المدى، حيث أن تحسين مجال واحد يكشف عن أوجه القصور في مجال آخر، ويتم تقليصها عادةً إذا كان الأداء مقبولاً أو إذا أصبحت المكاسب أصغر أو أقل تكلفة.
بما أن الأداء جزء من ميزات البرنامج- فإن البرنامج البطيء غير القابل للاستخدام لا يفي بالغرض: حيث تعد لعبة الفيديو 60هرتز (كادر في الثانية) مقبولة، لكن ذات 6 كادر في الثانية متقطعة وغير مقبولة- حيث يؤخذ الأداء بعين الاعتبار منذ البداية، وللتأكيد على أن النظام قادر على تقديم أداء كاف، فإن النماذج الأولية تحتاج إلى أداء مقبول على نحو تقديري للتأكد من أن النظام النهائي سيحقق أداء مقبول (مع التحسين). وفي بعض الأحيان يهمل للاعتقاد بأن التحسين دائماً يمكن أن يتم في وقت لاحق، محدثاً نظام أولي بطئ جداً أونظام يفشل في نهاية المطاف لأنه معمارياً لا يستطيع تحقيق أهداف الأداء الخاصة به مثل (Intel 432 (1981 أو تلك التي تستغرق سنوات من العمل لتحقيق أداء مقبول مثل (Java (1995 التي حققت أداءً مقبولاً فقط بنقطة الاتصال (HotٍٍSpot (1999. يمكن للدرجة التي يتغير بها الأداء ما بين النموذج الأولي والنظام النهائي وكيفية قابليته للتحسين أن تكون مصدراً كبيراً لعدم اليقين والمخاطر.
على مستوى التصميم
في أعلى مستوى يمكن تحسين التصميم، للحصول على الاستخدام الأمثل للمصادر المتاحة وتحقيق الأهداف المعطاة وعدم تجاوز القيود. حيث يؤثر التصميم المعماري للنظام تأثيراً بالغاً على أداءه. يتم اختيار التصميم بناءَ على الأهداف المراد تحقيقها: فعند تصميم المحول البرمجي(بالإنجليزية: Compiler)، إذا كانت سرعة الترجمة والتجميع هي الأولوية الرئيسية، فكومبايلر ذا مسار واحد أسرع من كومبايلر متعدد المسارات (يؤدي نفس العمل)، لكن إذا كانت سرعة إخراج التعليمات البرمجية هو الهدف، فإن كومبايلر متعدد المسارات أبطء سيفي بالغرض أكثر، على الرغم من أن الأمر يستغرق وقتاً أطول في حد ذاته. يتم اختيار البرنامج ولغة البرمجة في هذا المستوى، ويتطلب تغيرهم في كثير من الأحوال إعادة كتابة كاملة للبرنامج، بالرغم من أن نظام الوحدات قد يسمح بإعادة كتابة بعض المكونات فقط - على سبيل المثال، يمكن إعادة كتابة فقط بعض الأجزاء المهمة بلغة ال C لبرنامج كتب بلغة البايثون. في نظام التوزيع، يتم اختيار الهندسة المعمارية (خادم-عميل، نظير-إلى-نظير، إلخ) على مستوى التصميم، وقد يكون من الصعب تغيرها لاحقاً.
الخوارزميات وهيكلة البيانات
بعد التصميم، يؤثر اختيار الخوارزميات و بنية البيانات على الكفاءة أكثر من أي ميزات أخرى للبرنامج. فتعد هيكلة البيانات بصفة عامة أكثر صعوبة في التغيير من الخوارزميات، كما تستخدم افتراضات هيكلة البيانات وافتراضات أدائها من خلال البرنامج، على الرغم من أنه يمكن تقليص ذلك باستخدام أنواع بيانات مجردة في تعريفات الدالة وحفظ تعريفات بنية بيانات محددة تقتصر على أدوار قليلة.
بالنسبة للخوارزميات، لابد التأكد من أنها عبارة عن ثابت (O(1، لوغاريتمي (O(log n، خط مستقيم (O(n، مستقيم لوغاريتمي (O(n log n حيث المدخلات (المساحة والوقت). تخفق الخوارزميات ذات التعقيد الرباعي (O(n2 في القياس وحتى الخوارزميات الخطية تسبب مشاكل إذا تم استدعائها مراراً وتكراراً، وعادة ما يتم استبدال مع خوارزمية ثابت أو لوغاريتم إذا أمكن.
تعد التقنية العامة لتحسين الأداء هي تجنب الجهد. وخير مثال هو استخدام مسار سريع للحالات المتشابهة، محسناً الأداء عن طريق تجنب الجهد غير الضروري. على سبيل المثال، استخدام تصميم لوغاريتمي بنص بسيط للنص اللاتيني. يعد التخزين المؤقت الذي يجنبنا العمليات الحسابية الزائدة عن الحاجة تقنية أخرى ذات أهمية. ونظراً لأهمية التخزين المؤقت، غالباً ما تكون هناك مستويات عديدة للتخزين المؤقت في النظام الذي يمكن أن يسبب مشاكل من استخدام الذاكرة وصحة المعلومات في التخزين المؤقت.
مستوى البرنامج (code)
بعيداً عن اللوغاريتمات العامة وتطبيقاتها على الآلة المجردة، يمكن لخيارات مستوى التعليمات البرمجية أن تحدث فارقاً كبيراً. على سبيل المثال: (while(1 أبطأ من (;;)for، لأن تقييم (while(1 قفزة شرطية التي اختبرت إذا كان الأمر صحيحاً، بينما ل(؛؛)for كان لها قفزة غير مشروطة. حيث يمكن لبعض التحسينات هذه الأيام أن تتم عن طريق تحسين الكومبايلر. ويعتمد ذلك على لغة المصدر ولغة الجهاز المستهدف والكومبايلر، ويمكن أن يصعب كلاً من فهمه أو توقعه والتغيرات عبر الزمن؛ يعد هذا المكان الرئيسي حيث يمكن فهم المحولات البرمجية والتعليمات البرمجية للجهاز لتحسين الأداء. كما يعد كود الحلقة الثابتة وتحسين إرجاع القيمة أمثلة للتحسينات التي تقلل من الحاجة إلى المتغيرات الإضافية.
مستوى البناء
مستوى البناء بين مستوى البرنامج ومستوى الكومبايلر، يمكن للتعليمات والعلامات أن تستخدم لتقليص خيارات الأداء في التعليمات البرمجية للمصدر وبرنامج التحويل البرمجي على التوالي، مثل تعريف استخدام المعالج إلى تعطيل ميزات البرامج غير الضرورية، محسناً لنماذج معالج محددة أو قدرات الأجهزة، أو التنبؤ بالمنطق التفريعي، على سبيل المثال. كما يمكن لنظم توزيع البرامج المستندة إلى المصدر مثل المنقولات، توزيعة برمجيات بيركلي وبورتج جنتو من نموذج التحسين هذا على الوجه الأمثل.
مستوى التنسيق
يهدف استخدام كومبايلر محسن إلى التأكيد على أن البرنامج المنفذ معدل على الأقل بالقدر المتوقع من الكومبايلر.
مستوى التجميع
في المستوى الأدنى؛ يمكن أن تُنتج شفرة الكتابة باستخدام لغة التجميع المصممة لبرنامج أجهزة معينة والتي تعتبر أكثر الشفرات كفاءة إذا استفاد المبرمج من المجموعة الكاملة لتعليمات الآلة. تمت كتابة العديد من أنظمة التشغيل المستخدمة في الأنظمة المضمنة بلغة التجميع لأسباب الكفاءة. نادرًا ما تُكتب البرامج (بخلاف البرامج الصغيرة جدا) من البداية إلى النهاية بلغة التجميع بسبب الوقت والتكاليف المتعلقة بها. تُكتب غالباً بلغة عالية المستوى ثم إلى لغة التجميع ويتم التحسين اليدوي منها. عندما تكون الكفاءة والحجم أقل أهمية فربما تُكتب الأجزاء الكبيرة بلغة عالية المستوى.
مع المحولات البرمجية المحسنة الفعالة الجديدة و وحدات المعالجة المركزية الحديثة فإنه من الصعب كتابة الشفرة أكثر كفاءة مما ينتجه المترجم، وتحتاج القليل من المشاريع إلى خطوة التحسين "النهائية".
يراد تشغيل العديد من الشفرات المكتوبة اليوم على أكبر عدد ممكن من الأجهزة. نتيجة لذلك؛ لا يستفيد المبرمجون وبرامج الترجمة عادةً من التعليمات الأكثر كفاءة التي توفرها وحدات المعالجة المركزية الجديدة.
إجمالاً؛ سيستخدم المبرمجون مفككًا لتحليل ناتج برنامج الترجمة اليوم بدلاً من الكتابة بلغة التجميع وتغير الشفرة ذات المصدر عالي المستوى بحيث يمكن ترجمته بطريقة أكثر كفاءة أو فهم سبب عدم الكفاءة.
وقت التشغيل
يمكن أن ينتج برنامج الترجمة شفرة لجهاز مخصص معتمدة على بيانات وقت التشغيل على حساب تكلفة ترجمة البرامج. تعود هذه التقنية إلى تركيب التعابير النمطية والتي انتشرت على نطاق واسع Java HotSpot و V8 لJavaScript. في بعض الحالات؛ قد يكون التحسين التكيفي قادرًا على أداء التحسين وقت التنفيذ والذي يتجاوز قدرة برامج الترجمة الثابتة عن طريق ضبط المعاملات ديناميكيًا وفقًا للإدخال الفعلي أو العوامل الأخرى.
تقنية تحسين ترجمة البرامج في وقت سابق (بالإنجليزية: Profile-guided optimization) بناء على بيانات التعريف الخاصة بوقت التشغيل والمشابهة للنظير الثابت "متوسط الحالة" للتقنية الديناميكية الخاصة بالتحسين التكيفي.
يمكن أن يُبدل التعديل الذاتي للشفرة (بالإنجليزية: Self-modifying code) من تلقاء نفسه استجابة لظروف وقت التشغيل بهدف تحسين الشفرة. يعتبر ذلك أكثر شيوعًا في برامج لغة التجميع.
يمكن لبعض تصميمات وحدة المعالجة المركزية أداء بعض التحسينات في وقت التشغيل. تشتمل بعض الأمثلة على التنفيذ الخارج عن النظام والتنفيذ التخميني وخطوط أنابيب التعليمات والتنبؤات الفرعية.
