जब मैंने पायथन सीखना शुरू किया, मैंने कक्षाओं (केवल फ़ंक्शंस) के बिना कुछ एप्लिकेशन बनाए, अब मुझे कक्षाएं पता हैं और पता है कि कोड कक्षाओं के साथ फिर से लिखने पर बहुत पठनीय (और समझने में आसान) होगा।कक्षाओं के साथ पाइथन कोड धीमा है?
क्या कोड सामान्य रूप से कक्षाओं का उपयोग करेगा जब कोड बहुत धीमा होगा?
सं
सामान्य तौर पर आप वर्ग या नहीं के प्रयोग पर आधारित प्रदर्शन में कोई अंतर दिखाई नहीं देगा। निहित विभिन्न कोड संरचनाओं का अर्थ यह हो सकता है कि एक दूसरे की तुलना में तेज़ है, लेकिन यह कहना असंभव है।
हमेशा पढ़ने के लिए कोड लिखें, फिर, और केवल तभी, यह पर्याप्त तेज़ नहीं है। याद रखें: Premature optimization is the root of all evil।
बुराई रूट +1 – user3085931
-1 निश्चित संख्या हां के कारण, पठनीयता छोटे प्रदर्शन मतभेदों की तुलना में अधिक महत्वपूर्ण है, लेकिन एक विधि को कॉल करने में सीपीथॉन एक वैश्विक कार्य को कॉल करने से स्पष्ट रूप से धीमा है, जैसा कि ऑब्जेक्ट बनाने के समान धीमा है नक्शा बनाना मतभेद बहुत छोटे हैं, लेकिन कक्षाएं अभी भी वर्गीकृत विकल्पों की तुलना में धीमी हैं। – Dakkaron
@ डकारन, मुझे लगता है कि आप सही हो सकते हैं। मैंने यह पता लगाने के बाद पोस्ट किया कि मूल सूची डेटा संरचना के लिए एक रैपर के रूप में एक वर्ग का उपयोग कर एक ही सटीक फ़ंक्शन धीमा था: http://stackoverflow.com/questions/41781048/overhead-of-creating-classes-in -पिथॉन-सटीक-समान-कोड-उपयोग-वर्ग-दो बार-जैसा-स्लो –
आपको शायद उतना ही परवाह नहीं है जितना आप सोचते हैं।
वास्तव में।
निश्चित रूप से, कक्षाओं के साथ कोड संकेत के माध्यम से थोड़ा धीमा हो सकता है। शायद। जेआईटी संकलन यही है, है ना? मैं कभी भी याद नहीं कर सकता कि पाइथन के कौन से संस्करण ऐसा करते हैं और जो नहीं करते हैं, क्योंकि:
प्रदर्शन कोई फर्क नहीं पड़ता।
इस तरह कम से कम निरंतर प्रदर्शन अंतर। जब तक आप बहुत सारी गणनाओं का नरक नहीं कर रहे हैं (आप नहीं हैं!), आप अपने कोड को विकसित/डिबगिंग/बनाए रखने में अधिक समय व्यतीत करेंगे। इसके लिए अनुकूलित करें।
वास्तव में। क्योंकि आप कभी भी अंतर को मापने में सक्षम नहीं होंगे, जब तक कि आप एक तंग लूप में न हों। और आप इसे अजगर में ऐसा नहीं करना चाहते हैं, जब तक कि आप वास्तव में समय की परवाह नहीं करते हैं। ऐसा नहीं है कि आप पाइथन में अपने सेगवे को संतुलित करने की कोशिश कर रहे हैं, है ना? आप बस कुछ संख्याओं की गणना करना चाहते हैं, है ना? आपका कंप्यूटर इस पर वास्तव में अच्छा है। विशवास करो।
उस ने कहा, इसका मतलब यह नहीं है कि कक्षाएं जाने का रास्ता हैं। बस वह गति वह सवाल नहीं है जिसे आप पूछना चाहिए। इसके बजाय, यह पता लगाने का प्रयास करें कि आपके कोड के लिए कौन सा प्रतिनिधित्व सबसे अच्छा होगा। ऐसा लगता है, अब आप कक्षाएं जानते हैं, आप ओओ फैशन में स्वच्छ कोड लिखेंगे। आगे बढ़ें। जानें। दोहराएं।
"ऐसा नहीं है कि आप अपने सेगवे को पायथन में संतुलित करने की कोशिश कर रहे हैं, है ना?" असल में ... http://www.tlb.org/#scooter –
प्रश्न का उत्तर देने के लिए: हाँ, यह थोड़ा धीमा होने की संभावना है, अन्य सभी बराबर हैं। कुछ चीजें जो चर (वर्क समेत) के रूप में उपयोग की जाती हैं, अब ऑब्जेक्ट विशेषताओं के लिए जा रही हैं, और foofoo की तुलना में थोड़ा धीमी होने वाली है, भले ही foo मूल या स्थानीय मूल रूप से हो। (स्थानीय चर का उपयोग इंडेक्स द्वारा किया जाता है, और नाम से ग्लोबल्स, लेकिन किसी ऑब्जेक्ट पर एक विशेषता लुकअप या तो स्थानीय या वैश्विक लुकअप है, प्लस विशेषता के नाम से संभवतः कई स्थानों पर अतिरिक्त लुकअप है।) एक विधि को कॉल करना फ़ंक्शन को कॉल करने से थोड़ा धीमा है - न केवल विशेषता प्राप्त करने के लिए धीमा है, यह कॉल करने के लिए भी धीमा है, क्योंकि एक विधि एक रैपर ऑब्जेक्ट है जो आपके द्वारा लिखे गए फ़ंक्शन को कॉल करती है, अतिरिक्त फ़ंक्शन कॉल ओवरहेड जोड़ती है।
क्या यह ध्यान देने योग्य होगा? आमतौर पर नहीं। दुर्लभ मामलों में यह हो सकता है कि, यदि आप एक विशेष विधि में ऑब्जेक्ट विशेषता का उपयोग कर रहे हैं (हजारों या लाखों बार)। लेकिन उस स्थिति में आप विधि के शीर्ष पर स्थानीय चर foo पर self.foo असाइन कर सकते हैं, और स्थानीय चर के प्रदर्शन लाभ का 99.44% प्राप्त करने के लिए इसे स्थानीय नाम से संदर्भित कर सकते हैं।
संक्षेप में: एक मामूली प्रदर्शन हिट होगा, और जहां प्रदर्शन हिट मामूली से अधिक है, तो इसे कम करना आसान है। दूसरी ओर, आप घंटे को लिखने और कोड को बनाए रखने में सहेज सकते हैं, मानते हैं कि आपकी समस्या ऑब्जेक्ट-ओरिएंटेड समाधान में खुद को उधार देती है। और समय बचाने की संभावना है कि आप पाइथन जैसी भाषा का उपयोग क्यों कर रहे हैं।
कंप्यूटिंग के ग्रैंड पुराने दिमाग में से एक डोनाल्ड Knuth, इस अवलोकन के साथ श्रेय दिया जाता है कि "हमें छोटी क्षमता के बारे में भूल जाना चाहिए, समय के बारे में 9 7% कहते हैं: समयपूर्व अनुकूलन सभी बुराइयों की जड़ है।" स्पीड लाभ के आधार पर ऑब्जेक्ट उन्मुख लोगों की बजाय प्रक्रियात्मक तकनीकों का उपयोग करने का निर्णय लेना जो किसी भी तरह से महसूस नहीं किया जा सकता है, एक समझदार रणनीति नहीं है।
यदि आपका कोड काम करता है और संशोधित करने की आवश्यकता नहीं है तो इसे अकेले छोड़ने के लिए स्वतंत्र महसूस करें। यदि इसे संशोधित करने की आवश्यकता है तो आपको कक्षाओं को शामिल करने के लिए एक न्यायसंगत रिफैक्टरिंग पर विचार करना चाहिए, क्योंकि विकास के दौरान कार्यक्रम की पठनीयता गति से कहीं अधिक महत्वपूर्ण है। आप बेहतर रखरखाव में लाभ भी देखेंगे। केर्निगन और प्लॉगर के "प्रोग्रामिंग स्टाइल के तत्व" से एक पुराना देखा गया है:
सबसे पहले, इसे काम करें। फिर (यदि यह पर्याप्त तेज़ काम नहीं करता है) इसे तेजी से काम करें।
लेकिन, सबसे पहले और सबसे महत्वपूर्ण, पठनीयता के लिए जाएं। गंभीरता से।
शायद यह इस बात पर निर्भर करेगा कि आप इसे कैसे कार्यान्वित करते हैं और आपके कार्य क्या करते हैं। आप समय मॉड्यूल के साथ कुछ परीक्षण कर सकते हैं। –
सवाल सामान्य रूप से उत्तर देने के लिए सामान्य है। केस केस का उपयोग करने के लिए यह उपयोग मामले से काफी भिन्न होगा। बस कोशिश करो और मापें। यह भी सुनिश्चित करें कि प्रदर्शन वास्तव में एक मुद्दा है। –
यदि कक्षाओं का उपयोग करने से प्रदर्शन हिट (यदि कोई है) आपके लिए कोई महत्व था तो शायद आपको पहले स्थान पर पायथन का उपयोग नहीं करना चाहिए। इतनी छोटी जानकारी के बारे में चिंता न करें। कोड पठनीयता 99% मामलों में प्रदर्शन की तुलना में एक और अधिक महत्वपूर्ण कारक है। – soulcheck