सबसे पहले, कुछ स्पष्टीकरण: पायथन एक भाषा है। कई अलग-अलग व्याख्याकार हैं जो पायथन भाषा में लिखे गए कोड को निष्पादित कर सकते हैं। संदर्भ कार्यान्वयन (CPython) आमतौर पर वह है जिसे संदर्भित किया जाता है जब कोई "पायथन" के बारे में बात करता है जैसे कि यह एक कार्यान्वयन है, लेकिन प्रदर्शन विशेषताओं के बारे में बात करते समय सटीक होना महत्वपूर्ण है, क्योंकि वे कार्यान्वयन के बीच बेतहाशा भिन्न हो सकते हैं।
पायथन में प्रदर्शन के साथ समझौता किए बिना हम एसआरपी को कैसे और कहां से ग्रहण करते हैं, क्योंकि इसका अंतर्निहित कार्यान्वयन सीधे तौर पर इसे प्रभावित करता है?
केस 1.)
यदि आपके पास शुद्ध पायथन कोड है (<= पायथन भाषा संस्करण 3.5, 3.6 में "बीटा स्तर का समर्थन है") जो केवल शुद्ध पायथन मॉड्यूल पर निर्भर करता है, तो आप हर जगह SRP को गले लगा सकते हैं और इसे चलाने के लिए PyPy का उपयोग कर सकते हैं। PyPy ( https://morepypy.blogspot.com/2019/03/pypy-v71-released-now-uses-utf-8.html ) एक पायथन इंटरप्रिटर है, जिसमें जस्ट इन टाइम कंपाइलर (JIT) है और यह फ़ंक्शन को हटा सकता है ओवरहेड कॉल करें जब तक कि निष्पादित कोड (कुछ सेकंड IIRC) को ट्रेस करके "वार्म अप" करने के लिए पर्याप्त समय हो। **
यदि आप सीपीथॉन दुभाषिया का उपयोग करने के लिए प्रतिबंधित हैं, तो आप सी में लिखे गए विस्तार में धीमी गति से कार्य कर सकते हैं, जो पूर्व संकलित होगा और किसी भी दुभाषिया ओवरहेड से पीड़ित नहीं होगा। आप अभी भी हर जगह एसआरपी का उपयोग कर सकते हैं, लेकिन आपका कोड पायथन और सी के बीच विभाजित हो जाएगा। क्या यह चुनिंदा एसआरपी को छोड़ने की तुलना में बेहतर या बदतर है, लेकिन केवल पायथन कोड से चिपके रहना आपकी टीम पर निर्भर करता है, लेकिन यदि आपके पास प्रदर्शन के महत्वपूर्ण खंड हैं कोड, यह निस्संदेह CPython द्वारा व्याख्या किए गए सबसे अधिक अनुकूलित शुद्ध पायथन कोड से भी तेज होगा। पायथन के कई सबसे तेज गणितीय पुस्तकालय इस विधि (सुन्न और डरावना IIRC) का उपयोग करते हैं। जो केस 2 में एक अच्छा तर्क है ...
केस 2.)
यदि आपके पास पायथन कोड है जो C एक्सटेंशन का उपयोग करता है (या पुस्तकालयों पर निर्भर करता है जो C एक्सटेंशन का उपयोग करते हैं), PyPy उनके लिखे जाने के आधार पर उपयोगी हो सकता है या नहीं भी हो सकता है। देखें http://doc.pypy.org/en/latest/extending.html जानकारी के लिए, लेकिन सारांश CFFI न्यूनतम भूमि के ऊपर है कि जब तक ctypes धीमी (इसे प्रयोग PyPy के साथ भी धीमी CPython से हो सकता है) है
Cython ( https://cython.org/ ) एक और विकल्प है, जिसका मुझे उतना अनुभव नहीं है। मैं इसे पूर्णता के लिए उल्लेख करता हूं, इसलिए मेरा जवाब "अपने दम पर खड़ा हो सकता है", लेकिन किसी भी विशेषज्ञता का दावा नहीं करना चाहिए। मेरे सीमित उपयोग से, ऐसा महसूस हुआ कि मुझे PyPy के साथ "मुफ्त में" प्राप्त करने के लिए उसी गति में सुधार करने के लिए कड़ी मेहनत करनी पड़ी, और अगर मुझे PyPy से बेहतर कुछ चाहिए, तो अपना सी एक्सटेंशन लिखना इतना आसान था ( जिसका फायदा यह है कि अगर मैं कोड को कहीं और दोबारा इस्तेमाल करता हूं या इसका हिस्सा किसी लाइब्रेरी में निकालता हूं, तो मेरा सारा कोड अभी भी किसी पायथन इंटरप्रेटर के तहत चल सकता है और साइथन द्वारा चलाया जाना जरूरी नहीं है)।
मुझे साइथॉन में "बंद" होने का डर है, जबकि PyPy के लिए लिखा गया कोई भी कोड CPython के तहत चल सकता है।
** उत्पादन में PyPy पर कुछ अतिरिक्त नोट
किसी भी विकल्प को बनाने में बहुत सावधानी बरतें जो कि एक बड़े कोडबेस में "आपको लॉक करने" का व्यावहारिक प्रभाव है। क्योंकि कुछ (बहुत लोकप्रिय और उपयोगी) तीसरे पक्ष के पुस्तकालय पहले बताए गए कारणों के लिए अच्छा नहीं खेलते हैं, यह बाद में बहुत कठिन निर्णय ले सकता है यदि आपको पता है कि आपको उन पुस्तकालयों में से एक की आवश्यकता है। मेरा अनुभव मुख्य रूप से PyPy का उपयोग करके कुछ (लेकिन सभी नहीं) को गति देने के लिए किया गया है, जो एक कंपनी के वातावरण में प्रदर्शन के प्रति संवेदनशील हैं, जहां यह हमारे उत्पादन वातावरण में नगण्य जटिलता को जोड़ता है (हम पहले से ही कई भाषाओं में तैनात हैं, कुछ अलग-अलग प्रमुख संस्करणों के साथ 2.7 बनाम। 3.5 रन वैसे भी)।
मैंने PyPy और CPython दोनों का उपयोग करते हुए नियमित रूप से मुझे कोड लिखने के लिए मजबूर किया है जो केवल भाषा विनिर्देश द्वारा की गई गारंटी पर निर्भर करता है, न कि कार्यान्वयन विवरण पर जो किसी भी समय परिवर्तन के अधीन हैं। आप इस तरह के विवरण के बारे में सोचकर अतिरिक्त बोझ महसूस कर सकते हैं, लेकिन मैंने इसे अपने पेशेवर विकास में मूल्यवान पाया, और मुझे लगता है कि यह संपूर्ण रूप से पायथन पारिस्थितिकी तंत्र के लिए "स्वस्थ" है।