पोर्टेज 3.0 स्थिर रिलीज़ पहले ही घोषित

डेवलपर्स ने हाल ही में जो पैकेज प्रबंधन प्रणाली के प्रभारी हैं भारवाहन (जेंटू लिनक्स वितरण में) संस्करण 3.0 के स्थिर संस्करण को जारी करने की घोषणा की।

जिसमें, मुख्य नवीनता प्रस्तुत इस नई शाखा का वह कार्य है जो दीर्घावधि में किया गया था Python 3 में संक्रमण और Python 2.7 के लिए समर्थन की समाप्ति (कुछ ऐसा जो पहले से ही लंबे समय से देखा जा रहा था, क्योंकि यह शाखा कई महीनों से आधिकारिक तौर पर असमर्थित थी)

हमारे पास अच्छी खबर है! जेंटू पोर्टेज प्रोजेक्ट ने हाल ही में पैकेज मैनेजर के संस्करण 3.0 को स्थिर किया है।

नया क्या है? खैर, पोर्टेज का यह तीसरा संस्करण पायथन 2.7 के लिए समर्थन को हटा देता है, जो कि पूरे 2020 में जेंटू पायथन प्रोजेक्ट द्वारा मुख्य जेंटू रिपॉजिटरी में एक सतत प्रयास रहा है।

पायथन 2.7 के लिए समर्थन बंद करने के अलावा, एक और बड़ा बदलाव पोर्टेज 3.0 की इस नई स्थिर शाखा से क्या अलग है? विभिन्न अनुकूलनों का समावेश था इसकी अनुमति है गणनाएँ बहुत तेजी से करें (50% से 60% के बीच) निर्भरता निर्धारित करने से जुड़ा है।

दिलचस्प बात यह है कि कुछ डेवलपर्स ने अपने काम को तेज करने के लिए C/C++ या Go में निर्भरता रिज़ॉल्यूशन कोड को फिर से लिखने का सुझाव दिया, लेकिन वे बड़े प्रयास से मौजूदा समस्या को हल करने में कामयाब रहे।

और यह मौजूदा कोड की प्रोफाइलिंग से अधिकांश समय यही पता चलता है गणना यूज़_रिड्यूस और कैटपीकेजीस्प्लिट फ़ंक्शंस को कॉल करने के लिए समर्पित है तर्कों के दोहराए गए सेट के साथ (इस कार्य को चलाने वाले व्यक्ति का उल्लेख है कि उदाहरण के लिए, catpkgsplit फ़ंक्शन को 1-5 मिलियन बार कॉल किया गया था)।

समस्या का पता चलने पर, गणना में तेजी लाने के लिए इसका उल्लेख करें, कैशिंग लागू शब्दकोशों के माध्यम से इन कार्यों के परिणाम का।

इसके अलावा, उपयोगकर्ता द्वारा प्रदत्त पैच के कारण, पोर्टेज के नवीनतम संस्करण में अपग्रेड करने से निर्भरता गणना में 50-60% की तेजी आ सकती है। हमें अपने समुदाय को हमारे सॉफ़्टवेयर में भाग लेते देखना अच्छा लगता है! अधिक जानकारी के लिए, पैच प्रदान करने वाले समुदाय सदस्य की यह Reddit पोस्ट देखें। स्वस्थ रहें और जेंटू के साथ खाना पकाते रहें!

इसके अलावा यह भी बताता है कि lru_cache अंतर्निहित फ़ंक्शन इष्टतम था कैशिंग के इस कार्य के लिए, लेकिन यह 3.2 के बाद से केवल पायथन संस्करणों में ही उपलब्ध था।

बैकवर्ड अनुकूलता के लिए, lru_cache को बदलने के लिए एक स्टब भी जोड़ा गया था, लेकिन पोर्टेज 2.7 में पायथन 3.0 के लिए समर्थन समाप्त करने के निर्णय ने कार्य को बहुत सरल बना दिया और हमें इस परत के बिना काम करने की अनुमति दी।

मैंने यह समझने के लिए कि कौन सी सुविधाओं में सबसे अधिक समय लग रहा था, cProfile और vmprof के साथ पोर्टेज की प्रोफाइलिंग में कुछ समय बिताया। मैंने प्रोफाइलर आउटपुट से कुछ फ्लेमग्राफ भी तैयार किए, जो इस तरह दिखते थे। मैंने देखा कि कुछ फ़ंक्शन, जैसे use_reducey catpkgsplit, को समान तर्कों के साथ बहुत बार बुलाया जाता है (जैसे, 1 से 5 मिलियन बार, के लिए catpkgsplit). मैंने इन फ़ंक्शंस के आउटपुट को एक निर्देश में कैशिंग करने के लिए कुछ प्रयोग किए, और कुछ अच्छे स्पीडअप देखने के बाद, मैंने पोर्टेज डेवलपर सूची में एक पैच सबमिट किया। किसी ने पायथन बिलिन का उपयोग करने का सुझाव दियाlru_cache इसके बजाय फ़ंक्शन डेकोरेटर, लेकिन यह केवल पायथन 3.2 और उच्चतर में उपलब्ध है।

दूसरी ओर कैश के उपयोग ने थिंकपैड X220 पर "इमर्ज -uDvpU -with-bdeps = और @world" ऑपरेशन को 5 मिनट 20 सेकंड से घटाकर 3 मिनट 16 सेकंड (63%) कर दिया है। अन्य प्रणालियों पर परीक्षणों से पता चला है कि प्रदर्शन में कम से कम 48% की वृद्धि हुई है।

परिवर्तन तैयार करने वाले डेवलपर ने एक प्रोटोटाइप लागू करने का भी प्रयास किया निर्भरता समाधान कोड का C++ या जंग में, लेकिन कार्य बहुत कठिन निकला, चूँकि इसे पोर्ट करने के लिए बड़ी मात्रा में कोड की आवश्यकता थी, और साथ ही, यह संदिग्ध था कि परिणाम प्रयास के लायक था।

अंत में यदि आप इसके बारे में अधिक जानना चाहते हैं इस स्थिर शाखा के रिलीज़ नोट पर, आप विवरण देख सकते हैं निम्नलिखित लिंक में