स्पीड तुलना - व्याख्यात्मक भाषाओं में प्रक्रियात्मक बनाम ओओ

Question

व्याख्यात्मक प्रोग्रामिंग भाषाओं जैसे PHP और जावास्क्रिप्ट में, एक प्रक्रियात्मक दृष्टिकोण पर ऑब्जेक्ट ओरिएंटेड दृष्टिकोण के साथ जाने का क्या असर पड़ता है?

विशेष रूप से जो मैं खोज रहा हूं वह वेब अनुप्रयोग बनाने और प्रक्रियात्मक और ऑब्जेक्ट ओरिएंटेड दृष्टिकोणों के बीच चयन करने के लिए विचारों की एक चेकलिस्ट है, न केवल गति के लिए अनुकूलित करने के लिए, बल्कि रखरखाव भी। उद्धृत अनुसंधान और परीक्षण के मामले भी सहायक होंगे यदि आप इसे आगे की खोज करने वाले किसी भी लेख के बारे में जानते हैं।

नीचे पंक्ति: ओओ बनाम प्रक्रिया के साथ जाने पर, कितनी बड़ी (यदि कोई है) प्रदर्शन वास्तव में मारा जाता है?

Answer 1

शायद मैं पागल हूं लेकिन इस तरह के मामलों में गति के बारे में चिंता करने के लिए एक व्याख्यात्मक भाषा का उपयोग करना शेड पेंट करने के लिए रंग का पता लगाने की कोशिश करना है। आइए इस विचार में भी न आएं कि इस प्रकार का अनुकूलन पूरी तरह से पूर्व परिपक्व है।

जब आपने 'रखरखाव' कहा था तो आपने सिर पर नाखून मारा। मैं उस दृष्टिकोण का चयन करूंगा जो सबसे अधिक उत्पादक और सबसे अधिक रखरखाव योग्य है। यदि आपको बाद में गति की आवश्यकता है, तो यह एक व्याख्या की गई भाषा के अंदर प्रक्रियात्मक बनाम ऑब्जेक्ट उन्मुख कोडिंग प्रतिमानों के बीच स्विच करने से नहीं आ रहा है।

Answer 2

नीचे पंक्ति: नहीं, क्योंकि व्याख्या का ओवरहेड विधि प्रेषण के ऊपरी हिस्से को खत्म कर देता है।

Answer 3

यदि आप एक व्याख्या की गई भाषा का उपयोग कर रहे हैं, तो अंतर अप्रासंगिक है। यदि प्रदर्शन एक मुद्दा है तो आपको एक व्याख्या की गई भाषा का उपयोग नहीं करना चाहिए। दोनों इसके बारे में प्रदर्शन करेंगे।

Answer 4

मैंने वास्तव में एक वेबसाइट पर पाइथन में एक छोटा परीक्षण किया है जिसे मैंने बनाए रखा है और पाया है कि वे गति में लगभग बराबर हैं, प्रक्रियात्मक दृष्टिकोण एक दूसरे के दस हजारवें जैसे कुछ जीतने के साथ, लेकिन ओओ कोड इतना महत्वपूर्ण क्लीनर था कि मैंने अभ्यास को एक पुनरावृत्ति से अधिक समय तक जारी नहीं रखा।

तो वास्तव में, इससे कोई फर्क नहीं पड़ता (वैसे भी मेरे अनुभव में)।

Answer 5

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

बस अनुकूलन का पहला नियम याद रखें।

मत करो।

:)

Answer 6

दुर्भाग्य से, मैंने भी अपने परीक्षण किए हैं। मैंने परीक्षण की गति की, और यह वही है, लेकिन PHP में स्मृति_get_usage() को स्मृति उपयोग के लिए परीक्षण करते समय, मैंने ओओपी पक्ष पर भारी संख्या में देखा। प्रक्रिया के लिए

116,576 बाइट ओओपी के लिए 18,856 बाइट्स के लिए। मुझे पता है "हार्डवेयर सस्ता है", लेकिन चलो! उपयोग में 1,000% की वृद्धि? क्षमा करें, यह इष्टतम नहीं है। और एक बार में आपकी वेबसाइट पर कई उपयोगकर्ताओं को मारने के बाद, मुझे यकीन है कि आपकी रैम बस जलाएगी, या बाहर चली जाएगी। क्या मै गलत हु?

Answer 7

मेरे अनुभव में, भारी भार के तहत एक साइट को दबा दिया जाएगा और प्रक्रियात्मक से ओओपी कोड के साथ अधिक आसानी से उत्तरदायी बन जाएगा। कारण समझना आसान है।

ओओपी को प्रक्रियात्मक कोड की तुलना में स्मृति में चलाने के लिए बहुत अधिक स्मृति आवंटन (MALLOC) और बहुत अधिक संचालन की आवश्यकता होती है। इसके कार्यों को करने के लिए इसे बहुत अधिक CPU समय की आवश्यकता होती है।यह अनिवार्य रूप से 'ओवरहेड' है, जो प्रक्रियात्मक कोड के चारों ओर लपेटा जाता है, सीपीयू बोझ को निष्पादित करने के लिए जोड़ता है, खासकर डेटाबेस संचालन करते समय।

ओओपी की सुविधा जैसे कई प्रोग्रामर, सरल इंटरफेस के पीछे छिपे हुए छोटे काले बक्से बनाते हैं। हालांकि, मुझे उन साइटों को पुनर्जीवित करने के लिए अच्छी तरह से भुगतान किया गया है जो भारी उपयोगकर्ता लोड के तहत जवाब देने के लिए हमेशा के लिए ले रहे थे। ओओपी को बाहर निकालना और इसे सरल प्रक्रियात्मक कार्यों के साथ बदलना एक बड़ा अंतर बना।

यदि आप अपनी साइट को बहुत व्यस्त होने की उम्मीद नहीं करते हैं, तो हर तरह से ओओपी का उपयोग करें। यदि आप एक उच्च ट्रैफिक सिस्टम बना रहे हैं, तो आप प्रसंस्करण और हर बाइट को आउटपुट से प्रत्येक सीपीयू चक्र को पट्टी करना चाहते हैं।