تم الإعلان بالفعل عن الإصدار المستقر من Portage 3.0

المطورين مؤخرا المسؤولين عن نظام إدارة الحزم حمل (على توزيعة Gentoo Linux) عن إصدار النسخة المستقرة من الإصدار 3.0.

بحيث، الجدة الرئيسية من هذا الفرع الجديد المقدم ، هو العمل الذي تم تنفيذه على المدى الطويل على الانتقال إلى Python 3 ونهاية دعم Python 2.7 (شيء شوهد بالفعل قادمًا لفترة طويلة ، حيث كان هذا الفرع بدون دعم رسميًا لعدة أشهر)

لدينا أخبار جيدة! استقر مشروع Gentoo Portage مؤخرًا على الإصدار 3.0 من مدير الحزم.

ما هو الجديد؟ حسنًا ، هذا الإصدار الثالث من Portage يزيل دعم Python 2.7 ، والذي كان جهدًا مستمرًا في مستودع Gentoo الرئيسي بواسطة مشروع Gentoo Python طوال عام 2020.

بالإضافة إلى وقف دعم Python 2.7 ، تغيير كبير آخر التي تبرز من هذا الفرع الجديد المستقر من Portage 3.0 كان إدراج تحسينات مختلفة التي سمحوا بها إجراء الحسابات بشكل أسرع (بين 50٪ و 60٪) المرتبطة بتحديد التبعيات.

ومن المثير للاهتمام ، أن بعض المطورين اقترحوا إعادة كتابة رمز دقة التبعية في C / C ++ أو Go لتسريع عملهم ، لكنهم تمكنوا من حل المشكلة الحالية بجهد كبير.

وعليه أظهر ملف تعريف الكود الحالي أنه في معظم الأوقات عملية حسابية مخصص لاستدعاء دالتي use_reduce و catpkgsplit مع مجموعة متكررة من الحجج (يذكر الشخص الذي قاد هذا العمل أنه على سبيل المثال ، تم استدعاء وظيفة catpkgsplit من 1 إلى 5 ملايين مرة).

مع اكتشاف المشكلة ، اذكر ذلك لتسريع العمليات الحسابية ، تم تطبيق التخزين المؤقت من نتيجة هذه الوظائف بواسطة القواميس.

بالإضافة إلى ذلك ، وبسبب التصحيح الذي يوفره المستخدم ، يمكن للترقية إلى أحدث إصدار من Portage أن تسرع بشكل كبير حسابات التبعية بنسبة 50-60٪. نحن نحب أن نرى مجتمعنا يشارك في برنامجنا! لمزيد من التفاصيل ، تحقق من منشور Reddit هذا من عضو المجتمع الذي قدم التصحيح. حافظ على صحتك واستمر في الطهي مع Gentoo!

إلى جانب ذلك كما يشير أيضًا إلى أن الوظيفة المضمنة lru_cache كانت مثالية لمهمة التخزين المؤقت هذه ، لكنها كانت متوفرة فقط في إصدارات Python منذ 3.2.

من أجل التوافق مع الإصدارات السابقة ، تمت إضافة كعب لاستبدال lru_cache ، لكن قرار إنهاء دعم Python 2.7 في Portage 3.0 أدى إلى تبسيط المهمة بشكل كبير وجعل من الممكن تجاوز هذه الطبقة.

قضيت بعض الوقت في تحديد سمات Portage باستخدام cProfile و vmprof لفهم الميزات التي كانت تستغرق وقتًا أطول. لقد قمت أيضًا بإنشاء بعض الرسوم البيانية المشتعلة من نتائج ملف التعريف ، والتي بدت على هذا النحو. ما لاحظته هو أن بعض الوظائف ، مثل use_reducey catpkgsplit، يتم استدعاؤها بشكل متكرر بنفس الوسيطات (مثل ، من 1 إلى 5 ملايين مرة ، لـ catpkgsplit). لقد أجريت بعض التجارب لتخزين نتائج هذه الوظائف مؤقتًا في إملاء ، وبعد رؤية بعض عمليات التسريع الجيدة ، قمت بإرسال تصحيح إلى قائمة مطوري Portage. اقترح أحدهم استخدام لغة بايثون المضمنةlru_cache وظيفة decorator بدلاً من ذلك ، ولكن هذا متاح فقط في Python 3.2 والإصدارات الأحدث.

من ناحية أخرى ، أدى استخدام ذاكرة التخزين المؤقت إلى تقليل عملية "ظهور-uDvpU –with-bdeps = yworld" على ThinkPad X220 من 5 دقائق و 20 ثانية إلى 3 دقائق و 16 ثانية (63٪). أظهرت الاختبارات على الأنظمة الأخرى زيادة في الأداء بنسبة 48٪ على الأقل.

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

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