प्रोग्रामिंग पैराडाइम की तुलना: Difference between revisions
No edit summary |
No edit summary |
||
| Line 14: | Line 14: | ||
निम्नलिखित सामान्य प्रकार के प्रोग्रामिंग हैं जिन्हें विभिन्न प्रतिमानों का उपयोग करके कार्यान्वित किया जा सकता है: | निम्नलिखित सामान्य प्रकार के प्रोग्रामिंग हैं जिन्हें विभिन्न प्रतिमानों का उपयोग करके कार्यान्वित किया जा सकता है: | ||
* [[घटना-संचालित प्रोग्रामिंग]] - प्रोग्राम [[ बहाव को काबू करें ]] [[ घटना (कंप्यूटिंग) ]] द्वारा निर्धारित किया जाता है, जैसे [[सेंसर]] इनपुट या उपयोगकर्ता क्रियाएं ([[ कम्प्यूटर का माउस ]] क्लिक, कुंजी प्रेस) या अन्य प्रोग्राम या [[ धागा (कंप्यूटर विज्ञान) ]] से संदेश पास करना। | * [[घटना-संचालित प्रोग्रामिंग]] - प्रोग्राम [[ बहाव को काबू करें ]] [[ घटना (कंप्यूटिंग) ]] द्वारा निर्धारित किया जाता है, जैसे [[सेंसर]] इनपुट या उपयोगकर्ता क्रियाएं ([[ कम्प्यूटर का माउस ]] क्लिक, कुंजी प्रेस) या अन्य प्रोग्राम या [[ धागा (कंप्यूटर विज्ञान) ]] से संदेश पास करना। | ||
* [[ऑटोमेटा-आधारित प्रोग्रामिंग]] - | * [[ऑटोमेटा-आधारित प्रोग्रामिंग]] - प्रोग्राम, या भाग, को परिमित अवस्था मशीन या किसी अन्य औपचारिक ऑटोमेटन के मॉडल के रूप में माना जाता है। | ||
* [[ प्रतिक्रियाशील प्रोग्रामिंग ]] [[डेटाफ्लो प्रोग्रामिंग]] और परिवर्तन के प्रसार से संबंधित | * [[ प्रतिक्रियाशील प्रोग्रामिंग ]] [[डेटाफ्लो प्रोग्रामिंग]] और परिवर्तन के प्रसार से संबंधित घोषणात्मक प्रोग्रामिंग प्रतिमान है। | ||
ओओपी विधियों को लागू करने वाले सबरूटीन्स को अंततः | ओओपी विधियों को लागू करने वाले सबरूटीन्स को अंततः अनिवार्य, कार्यात्मक, या प्रक्रियात्मक शैली में कोडित किया जा सकता है, जो इनवोकिंग प्रोग्राम की ओर से [[राज्य (कंप्यूटर विज्ञान)]] को सीधे बदल सकता है या नहीं। प्रतिमानों के बीच अनिवार्य रूप से कुछ ओवरलैप है, लेकिन मुख्य विशेषताएं या पहचाने जाने योग्य अंतर इस तालिका में संक्षेप हैं: | ||
{| class="wikitable sortable" | {| class="wikitable sortable" | ||
| Line 87: | Line 87: | ||
== शब्दावली में अंतर == | == शब्दावली में अंतर == | ||
कई (प्रकार के) प्रोग्रामिंग प्रतिमानों के समानांतर (कभी-कभी स्पष्ट रूप से परस्पर विरोधी परिभाषाओं के साथ) मौजूद होने के बावजूद, अंतर्निहित [[सार]] के कई कमोबेश वही रहते हैं (निरंतर (प्रोग्रामिंग), [[चर (प्रोग्रामिंग)]], फील्ड (कंप्यूटर विज्ञान), [[सबरूटीन कॉल]] आदि) .) और समान रूप से समान विशेषताओं या कार्यों के साथ अनिवार्य रूप से प्रत्येक अलग प्रतिमान में शामिल किया जाना चाहिए। ऊपर दी गई तालिका सटीक समानताओं के लिए | कई (प्रकार के) प्रोग्रामिंग प्रतिमानों के समानांतर (कभी-कभी स्पष्ट रूप से परस्पर विरोधी परिभाषाओं के साथ) मौजूद होने के बावजूद, अंतर्निहित [[सार]] के कई कमोबेश वही रहते हैं (निरंतर (प्रोग्रामिंग), [[चर (प्रोग्रामिंग)]], फील्ड (कंप्यूटर विज्ञान), [[सबरूटीन कॉल]] आदि) .) और समान रूप से समान विशेषताओं या कार्यों के साथ अनिवार्य रूप से प्रत्येक अलग प्रतिमान में शामिल किया जाना चाहिए। ऊपर दी गई तालिका सटीक समानताओं के लिए गाइड के रूप में अभिप्रेत नहीं है, लेकिन प्रत्येक प्रतिमान के भीतर, इन संस्थाओं के अलग-अलग नामकरण के आधार पर, अधिक जानकारी के लिए कहाँ देखना है, इसका सूचकांक है। आगे जटिल मामले प्रत्येक प्रतिमान के गैर-मानकीकृत कार्यान्वयन हैं, कई [[प्रोग्रामिंग भाषा]]ओं में, विशेष रूप से [[बहु-प्रतिमान प्रोग्रामिंग भाषा]] का समर्थन करने वाली भाषाएं, प्रत्येक अपने स्वयं के [[शब्दजाल]] के साथ। | ||
== भाषा समर्थन == | == भाषा समर्थन == | ||
{{Main|Syntactic sugar}} | {{Main|Syntactic sugar}} | ||
[[सिंटैक्टिक चीनी]] भाषा की विशेषताओं को पेश करके प्रोग्राम की कार्यक्षमता को मधुर बनाना है जो किसी दिए गए उपयोग की सुविधा प्रदान करती है, भले ही उनके बिना अंतिम परिणाम प्राप्त किया जा सके। सिंटैक्टिक चीनी का | [[सिंटैक्टिक चीनी]] भाषा की विशेषताओं को पेश करके प्रोग्राम की कार्यक्षमता को मधुर बनाना है जो किसी दिए गए उपयोग की सुविधा प्रदान करती है, भले ही उनके बिना अंतिम परिणाम प्राप्त किया जा सके। सिंटैक्टिक चीनी का उदाहरण वस्तु-उन्मुख प्रोग्रामिंग भाषाओं में उपयोग की जाने वाली कक्षा (कंप्यूटर प्रोग्रामिंग) हो सकता है। अनिवार्य भाषा [[सी (प्रोग्रामिंग भाषा)]] [[समारोह सूचक]], टाइप कास्टिंग और संरचनाओं की सुविधाओं के माध्यम से [[ ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग ]] का समर्थन कर सकती है। हालाँकि, सी++ जैसी भाषाओं का उद्देश्य इस कोडिंग शैली के लिए सिंटैक्स विशिष्ट को पेश करके ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग को अधिक सुविधाजनक बनाना है। इसके अलावा, विशेष सिंटैक्स वस्तु-उन्मुख दृष्टिकोण पर जोर देने के लिए काम करता है। इसी तरह, सी (और अन्य प्रक्रियात्मक और संरचित प्रोग्रामिंग भाषाओं) में फ़ंक्शंस और लूपिंग सिंटैक्स को सिंटैक्टिक शुगर माना जा सकता है। [[ सभा की भाषा ]] प्रोग्राम स्टेट के आधार पर रजिस्टर वैल्यू और ब्रांचिंग एक्जीक्यूशन को संशोधित करने के लिए अपनी सुविधाओं के माध्यम से प्रक्रियात्मक या संरचित प्रोग्रामिंग का समर्थन कर सकती है। हालाँकि, सी जैसी भाषाओं ने प्रक्रियात्मक और संरचित प्रोग्रामिंग को अधिक सुविधाजनक बनाने के लिए इन कोडिंग शैलियों के लिए विशिष्ट सिंटैक्स पेश किया। सी # (सी शार्प) भाषा की विशेषताएं, जैसे गुण और इंटरफेस, इसी तरह कोई नया कार्य सक्षम नहीं करते हैं, लेकिन अच्छी प्रोग्रामिंग प्रथाओं को अधिक प्रमुख और प्राकृतिक बनाने के लिए डिज़ाइन किए गए हैं। | ||
कुछ प्रोग्रामर महसूस करते हैं कि ये सुविधाएँ महत्वहीन या तुच्छ हैं। उदाहरण के लिए, [[एलन पर्लिस]] ने एक बार [[ घुंघराले ब्रैकेट प्रोग्रामिंग भाषा ]] | ब्रैकेट-सीमांकित भाषाओं के संदर्भ में चुटकी ली, कि सिंटैक्टिक चीनी अर्धविराम के कैंसर का कारण बनती है ([[प्रोग्रामिंग पर एपिग्राम]] देखें)। | कुछ प्रोग्रामर महसूस करते हैं कि ये सुविधाएँ महत्वहीन या तुच्छ हैं। उदाहरण के लिए, [[एलन पर्लिस]] ने एक बार [[ घुंघराले ब्रैकेट प्रोग्रामिंग भाषा ]] | ब्रैकेट-सीमांकित भाषाओं के संदर्भ में चुटकी ली, कि सिंटैक्टिक चीनी अर्धविराम के कैंसर का कारण बनती है ([[प्रोग्रामिंग पर एपिग्राम]] देखें)। | ||
| Line 99: | Line 99: | ||
== प्रदर्शन तुलना == | == प्रदर्शन तुलना == | ||
केवल कुल निर्देश पथ लंबाई में, | केवल कुल निर्देश पथ लंबाई में, अनिवार्य शैली में कोडित प्रोग्राम, बिना किसी सबरूटीन्स का उपयोग करते हुए, सबसे कम गिनती होगी। हालाँकि, ऐसे प्रोग्राम का [[बाइनरी फ़ाइल]] आकार सबरूटीन्स (कार्यात्मक और प्रक्रियात्मक प्रोग्रामिंग के रूप में) का उपयोग करके कोड किए गए समान प्रोग्राम से बड़ा हो सकता है और संदर्भ के अधिक स्थानीयता को संदर्भित करेगा। गैर-स्थानीय भौतिक निर्देश जो कैशे (कंप्यूटिंग) #ऑपरेशन बढ़ा सकते हैं और निर्देश आधुनिक [[सेंट्रल प्रोसेसिंग यूनिट]] में [[कम्प्यूटेशनल ओवरहेड]] लाते हैं। | ||
प्रतिमान जो सबरूटीन्स का बड़े पैमाने पर उपयोग करते हैं (कार्यात्मक, प्रक्रियात्मक और वस्तु-उन्मुख सहित) और महत्वपूर्ण [[इनलाइन विस्तार]] (कंपाइलर अनुकूलन के माध्यम से इनलाइनिंग) का भी उपयोग नहीं करते हैं, परिणामस्वरूप, सबरूटीन लिंकेज पर कुल संसाधनों के | प्रतिमान जो सबरूटीन्स का बड़े पैमाने पर उपयोग करते हैं (कार्यात्मक, प्रक्रियात्मक और वस्तु-उन्मुख सहित) और महत्वपूर्ण [[इनलाइन विस्तार]] (कंपाइलर अनुकूलन के माध्यम से इनलाइनिंग) का भी उपयोग नहीं करते हैं, परिणामस्वरूप, सबरूटीन लिंकेज पर कुल संसाधनों के बड़े अंश का उपयोग करेंगे। ऑब्जेक्ट-ओरिएंटेड प्रोग्राम जो इन राज्य परिवर्तनों को समाहित करने के लिए [[म्यूटेटर विधि]]यों (या सेटर्स) का उपयोग करने के बजाय सीधे प्रोग्राम स्टेट को जानबूझकर नहीं बदलते हैं, प्रत्यक्ष परिणाम के रूप में, अधिक ओवरहेड होंगे। ऐसा इसलिए है क्योंकि संदेश पासिंग अनिवार्य रूप से सबरूटीन कॉल है, लेकिन तीन अतिरिक्त ओवरहेड्स के साथ: [[गतिशील स्मृति आवंटन]], पैरामीटर कॉपी और [[गतिशील प्रेषण]] हीप से मेमोरी प्राप्त करने और संदेश पास करने के लिए मापदंडों की प्रतिलिपि बनाने में महत्वपूर्ण संसाधन शामिल हो सकते हैं जो राज्य परिवर्तन के लिए आवश्यक संसाधनों से कहीं अधिक हैं। एक्सेसर्स (या गेटर्स) जो केवल निजी सदस्य चर के मान लौटाते हैं, कुल पथ लंबाई को जोड़ने के बजाय अधिक प्रत्यक्ष असाइनमेंट (या तुलना) का उपयोग करने के बजाय समान संदेश पासिंग सबरूटीन्स पर निर्भर करते हैं। | ||
=== [[प्रबंधित कोड]] === | === [[प्रबंधित कोड]] === | ||
| Line 108: | Line 108: | ||
=== [[स्यूडोकोड]] उदाहरण विभिन्न प्रतिमानों की तुलना === | === [[स्यूडोकोड]] उदाहरण विभिन्न प्रतिमानों की तुलना === | ||
सर्कल के क्षेत्र (πr²) की गणना करने के लिए उपयोग किए जाने वाले अनिवार्य, प्रक्रियात्मक और ऑब्जेक्ट ओरिएंटेड दृष्टिकोणों की | सर्कल के क्षेत्र (πr²) की गणना करने के लिए उपयोग किए जाने वाले अनिवार्य, प्रक्रियात्मक और ऑब्जेक्ट ओरिएंटेड दृष्टिकोणों की स्यूडोकोड तुलना, कोई सबरूटीन इनलाइन विस्तार नहीं, कोई [[ मैक्रो (कंप्यूटर विज्ञान) ]] [[ preprocessor ]] नहीं मानते, अंकगणित पंजीकृत करते हैं, और प्रत्येक निर्देश 'स्टेप' को केवल भारित करते हैं। 1 निर्देश - निर्देश पथ की लंबाई के कच्चे माप के रूप में - नीचे प्रस्तुत किया गया है। निर्देश चरण जो अवधारणात्मक रूप से राज्य परिवर्तन कर रहा है, प्रत्येक मामले में बोल्ड टाइपफेस में हाइलाइट किया गया है। सर्कल के क्षेत्र की गणना करने के लिए उपयोग किए जाने वाले अंकगणितीय संचालन तीनों प्रतिमानों में समान हैं, अंतर यह है कि प्रक्रियात्मक और वस्तु-उन्मुख प्रतिमान उन कार्यों को सबरूटीन कॉल में लपेटते हैं जो गणना को सामान्य और पुन: प्रयोज्य बनाता है। मैक्रो प्रीप्रोसेसर का उपयोग करते हुए विशुद्ध रूप से अनिवार्य प्रोग्राम में समान प्रभाव प्राप्त किया जा सकता है, केवल प्रोग्राम के आकार में वृद्धि (केवल प्रत्येक मैक्रो इनवोकेशन साइट पर) के बिना संबंधित [[यथानुपात]] रनटाइम लागत (एन इनवोकेशन के लिए आनुपातिक - जो एक के भीतर स्थित हो सकती है) आंतरिक पाश उदाहरण के लिए)। इसके विपरीत, कंपाइलर द्वारा सबरूटीन इनलाइनिंग प्रक्रियात्मक कार्यक्रमों को आकार में पूरी तरह अनिवार्य कोड के समान कुछ कम कर सकती है। हालाँकि, ऑब्जेक्ट-ओरिएंटेड प्रोग्राम के लिए, इनलाइनिंग के साथ भी, ऑब्जेक्ट-ओरिएंटेड तरीकों द्वारा प्रसंस्करण के लिए संदेशों को अभी भी (तर्कों की प्रतियों से) बनाया जाना चाहिए। कॉल का ओवरहेड, आभासी या अन्यथा, नियंत्रण प्रवाह परिवर्तन का प्रभुत्व नहीं है - लेकिन आसपास के [[कॉलिंग कन्वेंशन]] लागतों द्वारा, जैसे फ़ंक्शन प्रस्तावना कोड, स्टैक सेटअप और पैरामीटर (कंप्यूटर प्रोग्रामिंग)#पैरामीटर और तर्क पारित करना<ref>{{cite web|url=http://hbfs.wordpress.com/2008/12/30/the-true-cost-of-calls/ |title=कॉल की सही कीमत|date=2008-12-30|publisher=wordpress.com}}</ref> (यहाँ देखें<ref>{{Cite web|url=http://en.wikibooks.org/wiki/X86_Disassembly/Functions_and_Stack_Frames|title = X86 Disassembly/Functions and Stack Frames - Wikibooks, open books for an open world}}</ref> अधिक यथार्थवादी निर्देश पथ लंबाई, स्टैक और x[[86]] प्लेटफॉर्म पर कॉल से जुड़ी अन्य लागतों के लिए)। यहां भी देखें<ref>{{cite web|url=http://www-cs-faculty.stanford.edu/~eroberts/books/ArtAndScienceOfJava/slides/07-ObjectsAndMemory.ppt|title=Art and Science of Java; Chapter 7: Objects and Memory|last=Roberts|first=Eric S.|publisher=Stanford University|year=2008|access-date=2010-05-17|archive-url=https://web.archive.org/web/20110606103526/http://www-cs-faculty.stanford.edu/~eroberts/books/ArtAndScienceOfJava/slides/07-ObjectsAndMemory.ppt|archive-date=2011-06-06|url-status=dead}}</ref> एरिक एस रॉबर्ट्स द्वारा स्लाइड प्रस्तुति के लिए ( चर के लिए स्मृति का आवंटन , अध्याय 7)<ref>{{cite book|url=http://www-cs-faculty.stanford.edu/~eroberts/books/ArtAndScienceOfJava/slides/07-ObjectsAndMemory.ppt|title=जावा की कला और विज्ञान|last=Roberts|first=Eric S.|publisher=Addison-Wesley|year=2008|isbn=978-0-321-48612-7|access-date=2010-05-17|archive-url=https://web.archive.org/web/20110606103526/http://www-cs-faculty.stanford.edu/~eroberts/books/ArtAndScienceOfJava/slides/07-ObjectsAndMemory.ppt|archive-date=2011-06-06|url-status=dead}}</ref> - [[ जावा (प्रोग्रामिंग भाषा) ]] ऑब्जेक्ट-ओरिएंटेड लैंग्वेज में तीन परिमेय संख्याओं को जोड़ते समय स्टैक और हीप मेमोरी के उपयोग का चित्रण। | ||
{| class="wikitable" | {| class="wikitable" | ||
| Line 194: | Line 194: | ||
==== सबरूटीन, मेथड कॉल ओवरहेड ==== | ==== सबरूटीन, मेथड कॉल ओवरहेड ==== | ||
प्रोग्राम में (कहा जाता है) सबरूटीन की उपस्थिति प्रतिमान की परवाह किए बिना प्रोग्राम की कार्यक्षमता के लिए अतिरिक्त योगदान नहीं देती है, लेकिन प्रोग्राम की संरचना और व्यापकता में बहुत योगदान दे सकती है, जिससे इसे लिखना, संशोधित करना और विस्तार करना बहुत आसान हो जाता है।<ref name="steele1997">Guy Lewis Steele, Jr. "Debunking the 'Expensive Procedure Call' Myth, or, Procedure Call Implementations Considered Harmful, or, Lambda: The Ultimate GOTO". MIT AI Lab. AI Lab Memo AIM-443. October 1977. [http://repository.readscheme.org/ftp/papers/ai-lab-pubs/AIM-443.pdf] {{Webarchive|url=https://web.archive.org/web/20091229133005/http://repository.readscheme.org/ftp/papers/ai-lab-pubs/AIM-443.pdf |date=2009-12-29 }}[http://dspace.mit.edu/handle/1721.1/5753][http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.72.4404&rep=rep1&type=pdf]</ref> जिस हद तक अलग-अलग प्रतिमान सबरूटीन्स (और उनकी परिणामी मेमोरी आवश्यकताओं) का उपयोग करते हैं, वह संपूर्ण एल्गोरिथ्म के समग्र प्रदर्शन को प्रभावित करता है, हालांकि जैसा कि [[गाय स्टील]] ने 1977 के पेपर में बताया, अच्छी तरह से डिज़ाइन की गई प्रोग्रामिंग भाषा के कार्यान्वयन में प्रक्रियात्मक अमूर्तता के लिए बहुत कम ओवरहेड्स हो सकते हैं। (लेकिन अधिकांश कार्यान्वयनों में अफसोस जताते हैं, कि व्यवहार में वे शायद ही कभी इसे प्राप्त करते हैं - बल्कि इस संबंध में विचारहीन या लापरवाह होते हुए)। उसी पेपर में, स्टील ऑटोमेटा-आधारित प्रोग्रामिंग ([[ पूंछ पुनरावर्तन ]] के साथ प्रक्रिया कॉल का उपयोग करके) के लिए विचारित मामला भी बनाता है और निष्कर्ष निकालता है कि हमें प्रक्रिया कॉल के लिए स्वस्थ सम्मान होना चाहिए (क्योंकि वे शक्तिशाली हैं) लेकिन सुझाव दिया कि उन्हें कम से कम उपयोग करें<ref name="steele1997"/> | |||
उपनेमका कॉल की आवृत्ति में: | उपनेमका कॉल की आवृत्ति में: | ||
* प्रक्रियात्मक प्रोग्रामिंग के लिए, कोड की ग्रैन्युलैरिटी # डेटा ग्रैन्युलैरिटी काफी हद तक असतत प्रक्रियाओं या [[मॉड्यूलर प्रोग्रामिंग]] की संख्या से निर्धारित होती है। | * प्रक्रियात्मक प्रोग्रामिंग के लिए, कोड की ग्रैन्युलैरिटी # डेटा ग्रैन्युलैरिटी काफी हद तक असतत प्रक्रियाओं या [[मॉड्यूलर प्रोग्रामिंग]] की संख्या से निर्धारित होती है। | ||
* कार्यात्मक प्रोग्रामिंग के लिए, [[ पुस्तकालय (कम्प्यूटिंग) ]] सबरूटीन्स के लिए लगातार कॉल आम हैं,{{Citation needed|date=March 2010}} लेकिन अक्सर ऑप्टिमाइज़िंग कंपाइलर द्वारा इनलाइन किया जा सकता है | * कार्यात्मक प्रोग्रामिंग के लिए, [[ पुस्तकालय (कम्प्यूटिंग) ]] सबरूटीन्स के लिए लगातार कॉल आम हैं,{{Citation needed|date=March 2010}} लेकिन अक्सर ऑप्टिमाइज़िंग कंपाइलर द्वारा इनलाइन किया जा सकता है | ||
* ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग के लिए, कॉल किए गए मेथड कॉल्स की संख्या भी आंशिक रूप से डेटा संरचनाओं की ग्रैन्युलैरिटी द्वारा निर्धारित की जाती है और इस प्रकार निम्न स्तर की वस्तुओं के लिए कई रीड-ओनली एक्सेस शामिल हो सकते हैं जो इनकैप्सुलेटेड हैं, और इस प्रकार किसी अन्य में एक्सेस करने योग्य नहीं हैं, अधिक प्रत्यक्ष , रास्ता। चूंकि बढ़ी हुई ग्रैन्युलैरिटी अधिक [[कोड पुन: उपयोग]] के लिए | * ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग के लिए, कॉल किए गए मेथड कॉल्स की संख्या भी आंशिक रूप से डेटा संरचनाओं की ग्रैन्युलैरिटी द्वारा निर्धारित की जाती है और इस प्रकार निम्न स्तर की वस्तुओं के लिए कई रीड-ओनली एक्सेस शामिल हो सकते हैं जो इनकैप्सुलेटेड हैं, और इस प्रकार किसी अन्य में एक्सेस करने योग्य नहीं हैं, अधिक प्रत्यक्ष , रास्ता। चूंकि बढ़ी हुई ग्रैन्युलैरिटी अधिक [[कोड पुन: उपयोग]] के लिए शर्त है, प्रवृत्ति ठीक-ठाक डेटा संरचनाओं की ओर है, और असतत वस्तुओं (और उनकी विधियों) की संख्या में वृद्धि और इसके परिणामस्वरूप, सबरूटीन कॉल। [[देव वस्तु]]ओं के निर्माण को सक्रिय रूप से हतोत्साहित किया जाता है। [[कंस्ट्रक्टर (ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग)]] भी गिनती में जोड़ते हैं क्योंकि वे सबरूटीन कॉल भी हैं (जब तक कि वे इनलाइन न हों)। जब तक [[ scalability ]] समस्या नहीं बन जाती, तब तक अत्यधिक ग्रैन्युलैरिटी के कारण होने वाली प्रदर्शन समस्याएं स्पष्ट नहीं हो सकती हैं। | ||
* अन्य प्रतिमानों के लिए, जहाँ उपरोक्त प्रतिमानों का मिश्रण नियोजित किया जा सकता है, सबरूटीन का उपयोग कम अनुमानित है। | * अन्य प्रतिमानों के लिए, जहाँ उपरोक्त प्रतिमानों का मिश्रण नियोजित किया जा सकता है, सबरूटीन का उपयोग कम अनुमानित है। | ||
==== संदेश और वस्तु भंडारण के लिए गतिशील स्मृति का आवंटन ==== | ==== संदेश और वस्तु भंडारण के लिए गतिशील स्मृति का आवंटन ==== | ||
विशिष्ट रूप से, ऑब्जेक्ट-ओरिएंटेड प्रतिमान में ऑब्जेक्ट निर्माण और संदेश पासिंग दोनों के लिए हीप स्टोरेज से डायनेमिक मेमोरी आवंटन शामिल है। 1994 का बेंचमार्क - [[डिजिटल उपकरण निगम]] द्वारा विभिन्न प्रकार के सॉफ़्टवेयर पर संचालित बड़े सी और सी++ प्रोग्राम में मेमोरी एलोकेशन कॉस्ट, | विशिष्ट रूप से, ऑब्जेक्ट-ओरिएंटेड प्रतिमान में ऑब्जेक्ट निर्माण और संदेश पासिंग दोनों के लिए हीप स्टोरेज से डायनेमिक मेमोरी आवंटन शामिल है। 1994 का बेंचमार्क - [[डिजिटल उपकरण निगम]] द्वारा विभिन्न प्रकार के सॉफ़्टवेयर पर संचालित बड़े सी और सी++ प्रोग्राम में मेमोरी एलोकेशन कॉस्ट, इंस्ट्रक्शन-लेवल प्रोफाइलिंग टूल का उपयोग करके मापा गया कि डायनेमिक स्टोरेज आवंटन के लिए कितने निर्देश आवश्यक थे। परिणामों से पता चला कि निष्पादित निर्देशों की सबसे कम निरपेक्ष संख्या औसतन लगभग 50 थी, लेकिन अन्य 611 तक पहुंच गए।<ref>{{cite journal |journal=Software: Practice and Experience |title=Memory Allocation Costs in Large C and C++ Programs; Page 532 |first1= David |last1= Detlefs |first2= Al |last2 = Dosser |first3= Benjamin |last3= Zorn |volume=24|issue=6 |pages= 527–542 |date=June 1994 |citeseerx=10.1.1.30.3073|doi=10.1002/spe.4380240602 |s2cid=14214110 }}</ref> मुरली आर. कृष्णन द्वारा हीप: सुख और पीड़ा भी देखें<ref>{{cite web|url=http://msdn.microsoft.com/en-us/library/ms810466%28v=MSDN.10%29.aspx|publisher=microsoft.com|title=Heap: Pleasures and pains|last=Krishnan|first=Murali R.|date=February 1999}}</ref> यह बताता है कि ढेर कार्यान्वयन सभी प्लेटफार्मों के लिए सामान्य रहता है, और इसलिए भारी ओवरहेड होता है। आईबीएम के अरुण अयंगर द्वारा 1996 का आईबीएम पेपर स्केलेबिलिटी ऑफ डायनामिक स्टोरेज एलोकेशन एल्गोरिदम <ref>{{cite document |citeseerx=10.1.1.3.3759 |title=गतिशील भंडारण आवंटन एल्गोरिदम की मापनीयता|year=1996}}</ref> विभिन्न डायनेमिक स्टोरेज एल्गोरिदम और उनके संबंधित निर्देश काउंट को प्रदर्शित करता है। यहां तक कि अनुशंसित एमएफएलएफ I एल्गोरिदम (एचएस स्टोन, आरसी 9674) 200 और 400 के बीच की सीमा में निर्देश गणना दिखाता है। उपरोक्त स्यूडोकोड उदाहरण में इस स्मृति आवंटन पथ की लंबाई या स्मृति उपसर्ग ओवरहेड शामिल नहीं है और बाद में संबंधित कचरा शामिल नहीं है। संग्रह ओवरहेड्स। दृढ़ता से सुझाव देते हुए कि हीप आवंटन गैर-तुच्छ कार्य है, गेम डेवलपर जॉन डब्ल्यू रैटक्लिफ द्वारा [[खुला स्रोत सॉफ्टवेयर]] माइक्रोएलोकेटर, जिसमें कोड की लगभग 1,000 पंक्तियाँ होती हैं।<ref>{{cite web |url=http://code.google.com/p/microallocator/ |title=माइक्रोआवंटक.एच|work=Google Code |access-date=2012-01-29}}</ref> | ||
==== गतिशील रूप से प्रेषित संदेश कॉल वी। प्रत्यक्ष प्रक्रिया कॉल ओवरहेड्स ==== | ==== गतिशील रूप से प्रेषित संदेश कॉल वी। प्रत्यक्ष प्रक्रिया कॉल ओवरहेड्स ==== | ||
स्टेटिक क्लास पदानुक्रम विश्लेषण का उपयोग करके ऑब्जेक्ट-ओरिएंटेड प्रोग्राम के उनके सार अनुकूलन में,<ref>{{cite book |chapter=Optimization of Object-Oriented Programs Using Static Class Hierarchy Analysis |first1= Jeffrey |last1= Dean |first2= David |last2= Grove |first3= Craig |last3= Chambers |title= ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग|volume= 952 |pages= 77–101 |publisher=University of Washington |doi=10.1007/3-540-49538-X_5 |isbn= 978-3-540-60160-9 |citeseerx=10.1.1.117.2420|series= Lecture Notes in Computer Science |year= 1995 }}</ref> [[वाशिंगटन विश्वविद्यालय]] में कंप्यूटर विज्ञान और इंजीनियरिंग विभाग के जेफरी डीन, डेविड ग्रोव और क्रेग चेम्बर्स का दावा है कि वंशानुक्रम और गतिशील रूप से बाध्य संदेशों के भारी उपयोग से कोड को अधिक विस्तार योग्य और पुन: प्रयोज्य बनाने की संभावना है, लेकिन यह | स्टेटिक क्लास पदानुक्रम विश्लेषण का उपयोग करके ऑब्जेक्ट-ओरिएंटेड प्रोग्राम के उनके सार अनुकूलन में,<ref>{{cite book |chapter=Optimization of Object-Oriented Programs Using Static Class Hierarchy Analysis |first1= Jeffrey |last1= Dean |first2= David |last2= Grove |first3= Craig |last3= Chambers |title= ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग|volume= 952 |pages= 77–101 |publisher=University of Washington |doi=10.1007/3-540-49538-X_5 |isbn= 978-3-540-60160-9 |citeseerx=10.1.1.117.2420|series= Lecture Notes in Computer Science |year= 1995 }}</ref> [[वाशिंगटन विश्वविद्यालय]] में कंप्यूटर विज्ञान और इंजीनियरिंग विभाग के जेफरी डीन, डेविड ग्रोव और क्रेग चेम्बर्स का दावा है कि वंशानुक्रम और गतिशील रूप से बाध्य संदेशों के भारी उपयोग से कोड को अधिक विस्तार योग्य और पुन: प्रयोज्य बनाने की संभावना है, लेकिन यह गैर-ऑब्जेक्ट-ओरिएंटेड तरीके से लिखे गए समतुल्य लेकिन गैर-विस्तार योग्य प्रोग्राम के सापेक्ष महत्वपूर्ण प्रदर्शन ओवरहेड। कुछ डोमेन में, जैसे कि संरचित ग्राफ़िक्स पैकेज, भारी वस्तु-उन्मुख शैली का उपयोग करके प्रदान किए गए अतिरिक्त लचीलेपन की प्रदर्शन लागत स्वीकार्य है। हालाँकि, अन्य डोमेन में, जैसे कि बुनियादी डेटा संरचना लाइब्रेरी, संख्यात्मक कंप्यूटिंग पैकेज, रेंडरिंग लाइब्रेरी और ट्रेस-संचालित सिमुलेशन फ्रेमवर्क, संदेश पास करने की लागत बहुत अधिक हो सकती है, जिससे प्रोग्रामर को "हॉट" में ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग से बचने के लिए मजबूर होना पड़ता है। स्पॉट ”उनके आवेदन के। | ||
=== वस्तुओं को क्रमबद्ध करना === | === वस्तुओं को क्रमबद्ध करना === | ||
{{Main|Serialization}} | {{Main|Serialization}} | ||
[[क्रमबद्धता]] ऑब्जेक्ट (कंप्यूटर साइंस) को | [[क्रमबद्धता]] ऑब्जेक्ट (कंप्यूटर साइंस) को सिस्टम से दूसरे सिस्टम में पास करते समय बड़े ओवरहेड्स लगाता है, खासकर जब ट्रांसफर मानव-पठनीय प्रारूपों जैसे एक्सटेंसिबल मार्कअप लैंग्वेज ([[एक्सएमएल]]) और जावास्क्रिप्ट ऑब्जेक्ट नोटेशन (जेएसओएन) में होता है। यह गैर-ऑब्जेक्ट उन्मुख डेटा के लिए कॉम्पैक्ट बाइनरी प्रारूपों के विपरीत है। ऑब्जेक्ट के डेटा मान और इसकी विशेषताओं के एन्कोडिंग और डिकोडिंग दोनों क्रमबद्ध प्रक्रिया में शामिल हैं, जिसमें विरासत, एनकैप्सुलेटिंग और डेटा छिपाने जैसे जटिल मुद्दों के बारे में जागरूकता भी शामिल है। | ||
=== समानांतर कंप्यूटिंग === | === समानांतर कंप्यूटिंग === | ||
{{Main|Parallel computing}} | {{Main|Parallel computing}} | ||
मार्च 2011 में कार्नेगी-मेलन विश्वविद्यालय के प्रोफेसर [[रॉबर्ट हार्पर (कंप्यूटर वैज्ञानिक)]] ने लिखा: इस सेमेस्टर डैन लिकाटा और मैं प्रथम वर्ष के संभावित सीएस मेजर्स के लिए कार्यात्मक प्रोग्रामिंग पर | मार्च 2011 में कार्नेगी-मेलन विश्वविद्यालय के प्रोफेसर [[रॉबर्ट हार्पर (कंप्यूटर वैज्ञानिक)]] ने लिखा: इस सेमेस्टर डैन लिकाटा और मैं प्रथम वर्ष के संभावित सीएस मेजर्स के लिए कार्यात्मक प्रोग्रामिंग पर नया पाठ्यक्रम सह-शिक्षण दे रहे हैं। परिचयात्मक पाठ्यक्रम, क्योंकि यह अपनी प्रकृति से मॉड्यूलर और विरोधी समानांतर दोनों है, और इसलिए आधुनिक सीएस पाठ्यक्रम के लिए अनुपयुक्त है। उन छात्रों के लिए जो इस विषय का अध्ययन करना चाहते हैं, द्वितीय स्तर पर वस्तु-उन्मुख डिजाइन पद्धति पर प्रस्तावित नया पाठ्यक्रम पेश किया जाएगा।<ref>[http://existentialtype.wordpress.com/2011/03/15/teaching-fp-to-freshmen/ Teaching FP to Freshmen], from Harper's blog about teaching introductory computer science.[http://existentialtype.wordpress.com/2011/03/15/getting-started/]</ref> | ||
Revision as of 12:16, 19 May 2023
यह आलेख विकीपीडिया के मौजूदा लेखों में इन समानताओं और अंतरों से संबंधित अलग-अलग चर्चाओं के लिंक के साथ ग्राफिकल और सारणीबद्ध प्रारूप दोनों में सारांश के रूप में विभिन्न प्रोग्रामिंग प्रतिमानों के बीच विभिन्न समानताओं और अंतरों को निर्धारित करने का प्रयास करता है।
मुख्य प्रतिमान दृष्टिकोण
प्रोग्रामिंग के दो मुख्य दृष्टिकोण हैं:[1]
- अनिवार्य प्रोग्रामिंग - क्रियान्वित करने के तरीके पर ध्यान केंद्रित करता है, नियंत्रण प्रवाह को कथन (प्रोग्रामिंग) के रूप में परिभाषित करता है जो प्रोग्राम की स्थिति (कंप्यूटर विज्ञान) को बदल देता है।
- घोषणात्मक प्रोग्रामिंग - क्या निष्पादित करना है इस पर ध्यान केंद्रित करता है, प्रोग्राम लॉजिक को परिभाषित करता है, लेकिन विस्तृत नियंत्रण प्रवाह नहीं।
निम्नलिखित को व्यापक रूप से मुख्य प्रोग्रामिंग प्रतिमान माना जाता है, जैसा कि प्रोग्रामिंग भाषा की लोकप्रियता को मापते समय देखा जाता है:
- प्रक्रियात्मक प्रोग्रामिंग - उन चरणों को निर्दिष्ट करता है जो प्रोग्राम को वांछित स्थिति तक पहुंचने के लिए उठाने चाहिए।
- कार्यात्मक प्रोग्रामिंग - कार्यक्रमों को मूल्यांकन कार्य (गणित) के रूप में मानता है और प्रोग्राम की स्थिति और अपरिवर्तनीय वस्तु डेटा से बचता है।
- ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग | ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग (OOP) - प्रोग्राम को वस्तु (कंप्यूटर विज्ञान) के रूप में व्यवस्थित करता है: विशेषता (कंप्यूटिंग) और विधि (कंप्यूटर विज्ञान) से मिलकर डेटा संरचना उनकी बातचीत के साथ।
निम्नलिखित सामान्य प्रकार के प्रोग्रामिंग हैं जिन्हें विभिन्न प्रतिमानों का उपयोग करके कार्यान्वित किया जा सकता है:
- घटना-संचालित प्रोग्रामिंग - प्रोग्राम बहाव को काबू करें घटना (कंप्यूटिंग) द्वारा निर्धारित किया जाता है, जैसे सेंसर इनपुट या उपयोगकर्ता क्रियाएं (कम्प्यूटर का माउस क्लिक, कुंजी प्रेस) या अन्य प्रोग्राम या धागा (कंप्यूटर विज्ञान) से संदेश पास करना।
- ऑटोमेटा-आधारित प्रोग्रामिंग - प्रोग्राम, या भाग, को परिमित अवस्था मशीन या किसी अन्य औपचारिक ऑटोमेटन के मॉडल के रूप में माना जाता है।
- प्रतिक्रियाशील प्रोग्रामिंग डेटाफ्लो प्रोग्रामिंग और परिवर्तन के प्रसार से संबंधित घोषणात्मक प्रोग्रामिंग प्रतिमान है।
ओओपी विधियों को लागू करने वाले सबरूटीन्स को अंततः अनिवार्य, कार्यात्मक, या प्रक्रियात्मक शैली में कोडित किया जा सकता है, जो इनवोकिंग प्रोग्राम की ओर से राज्य (कंप्यूटर विज्ञान) को सीधे बदल सकता है या नहीं। प्रतिमानों के बीच अनिवार्य रूप से कुछ ओवरलैप है, लेकिन मुख्य विशेषताएं या पहचाने जाने योग्य अंतर इस तालिका में संक्षेप हैं:
| उदाहरण | विवरण | प्रमुख लक्षण | संबंधित उदाहरण | आलोचना | उदाहरण |
|---|---|---|---|---|---|
| अनिवार्य | कथनों के रूप में प्रोग्राम जो सीधे गणना की गई स्थिति (डेटाफ़ील्ड) को बदलते हैं | प्रत्यक्ष कार्य, सामान्य डेटा संरचनाएं, वैश्विक चर | एडजर डब्ल्यू. डिज्कस्ट्रा, माइकल ए. जैक्सन | सी, सी++, जावा, कोटलिन, पीएचपी, पायथन, रूबी | |
| स्ट्रक्चर्ड | अधिक तार्किक प्रोग्राम संरचना के साथ अनिवार्य प्रोग्रामिंग की शैली | स्ट्रक्चरोग्राम, इंडेंटेशन, गोटो स्टेटमेंट का कोई या सीमित उपयोग नहीं | अनिवार्य | सी, सी++, जावा, कोटलिन, Pascal, पीएचपी, पायथन | |
| प्रक्रियात्मक | मॉड्यूलर प्रोग्रामिंग या प्रक्रिया कॉल की अवधारणा के आधार पर संरचित प्रोग्रामिंग से व्युत्पन्न | स्थानीय चर, अनुक्रम, चयन, पुनरावृत्ति और मॉडर्लाइज़ेशन | संरचित, अनिवार्य | सी, सी++, लिस्प, पीएचपी, पायथन | |
| कार्यात्मक | गणना को स्तर और परिवर्तनशील डेटा से बचने वाले गणितीय कार्यों के मूल्यांकन के रूप में मानता है | लैम्ब्डा कैलकुस, संरचना, सूत्र, रिकर्सन, रेफरेंसियल पारदर्शिता, कोई साइड इफेक्ट नहीं | वर्णनात्मक | सी++,[2] सी#,[3][circular reference] क्लोजर, कॉफीस्क्रिप्ट,[4] एलिक्सिर, एर्लैंग, F#, हास्केल, जावा (वर्जन के बाद से 8), कोटलिन, लिस्प, पायथन, R,[5] रूबी, स्काला, सीक्वेंस एल, स्टैंडर्ड एमएल, जावास्क्रिप्ट, एल्म | |
| समय-संचालित सहित घटना-संचालित | नियंत्रण प्रवाह मुख्य रूप से घटनाओं द्वारा निर्धारित किया जाता है, जैसे कि माउस क्लिक या टाइमर सहित व्यवधान | मेन लूप, इवेंट हैंडलर, एसिंक्रोनस प्रोसेस | प्रक्रियात्मक, डेटा प्रवाह | जावास्क्रिप्ट, एक्शनस्क्रिप्ट, विजुअल बेसिक, एल्म | |
| ऑब्जेक्ट-ओरिएंटेड | डेटाफ़ील्ड को केवल पूर्वनिर्धारित विधियों के माध्यम से हेरफेर की गई वस्तुओं के रूप में मानता है | वस्तुएं, विधियाँ, संदेश पास करना, सूचना छिपाना, डेटा अमूर्तता, एनकैप्सुलेशन, बहुरूपता, वंशानुक्रम, क्रमांकन-मार्शलिंग | प्रक्रियात्मक | इसकी आलोचना चयन और अन्यत्र देखें [6][7][8] | सामान्य लिस्प, सी++, सी#, आइफिल, जावा, कोटलिन, पीएचपी, पायथन, रूबी, स्काला, जावास्क्रिप्ट[9][10] |
| वर्णनात्मक | प्रोग्राम लॉजिक को परिभाषित करता है, किन्तु विस्तृत नियंत्रण प्रवाह को नहीं | चौथी पीढ़ी की भाषाएं, स्प्रेडशीट, रिपोर्ट प्रोग्राम जेनरेटर | एसक्यूएल, रेगुलर एक्सप्रेशंस, प्रोलॉग, ओडब्ल्यूएल, स्पार्कल, डेटा लॉग, एक्सएसएलटी | ||
| ऑटोमेटा-आधारित प्रोग्रामिंग | प्रोग्राम को परिमित अवस्था मशीन या किसी अन्य औपचारिक ऑटोमेटा के मॉडल के रूप में मानता है | स्तर गणना, नियंत्रण चर, स्तर परिवर्तन, समरूपता, स्तर संक्रमण तालिका | अनिवार्य, घटना-संचालित | एब्स्ट्रैक्ट स्टेट मशीन लैंग्वेज |
शब्दावली में अंतर
कई (प्रकार के) प्रोग्रामिंग प्रतिमानों के समानांतर (कभी-कभी स्पष्ट रूप से परस्पर विरोधी परिभाषाओं के साथ) मौजूद होने के बावजूद, अंतर्निहित सार के कई कमोबेश वही रहते हैं (निरंतर (प्रोग्रामिंग), चर (प्रोग्रामिंग), फील्ड (कंप्यूटर विज्ञान), सबरूटीन कॉल आदि) .) और समान रूप से समान विशेषताओं या कार्यों के साथ अनिवार्य रूप से प्रत्येक अलग प्रतिमान में शामिल किया जाना चाहिए। ऊपर दी गई तालिका सटीक समानताओं के लिए गाइड के रूप में अभिप्रेत नहीं है, लेकिन प्रत्येक प्रतिमान के भीतर, इन संस्थाओं के अलग-अलग नामकरण के आधार पर, अधिक जानकारी के लिए कहाँ देखना है, इसका सूचकांक है। आगे जटिल मामले प्रत्येक प्रतिमान के गैर-मानकीकृत कार्यान्वयन हैं, कई प्रोग्रामिंग भाषाओं में, विशेष रूप से बहु-प्रतिमान प्रोग्रामिंग भाषा का समर्थन करने वाली भाषाएं, प्रत्येक अपने स्वयं के शब्दजाल के साथ।
भाषा समर्थन
सिंटैक्टिक चीनी भाषा की विशेषताओं को पेश करके प्रोग्राम की कार्यक्षमता को मधुर बनाना है जो किसी दिए गए उपयोग की सुविधा प्रदान करती है, भले ही उनके बिना अंतिम परिणाम प्राप्त किया जा सके। सिंटैक्टिक चीनी का उदाहरण वस्तु-उन्मुख प्रोग्रामिंग भाषाओं में उपयोग की जाने वाली कक्षा (कंप्यूटर प्रोग्रामिंग) हो सकता है। अनिवार्य भाषा सी (प्रोग्रामिंग भाषा) समारोह सूचक, टाइप कास्टिंग और संरचनाओं की सुविधाओं के माध्यम से ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग का समर्थन कर सकती है। हालाँकि, सी++ जैसी भाषाओं का उद्देश्य इस कोडिंग शैली के लिए सिंटैक्स विशिष्ट को पेश करके ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग को अधिक सुविधाजनक बनाना है। इसके अलावा, विशेष सिंटैक्स वस्तु-उन्मुख दृष्टिकोण पर जोर देने के लिए काम करता है। इसी तरह, सी (और अन्य प्रक्रियात्मक और संरचित प्रोग्रामिंग भाषाओं) में फ़ंक्शंस और लूपिंग सिंटैक्स को सिंटैक्टिक शुगर माना जा सकता है। सभा की भाषा प्रोग्राम स्टेट के आधार पर रजिस्टर वैल्यू और ब्रांचिंग एक्जीक्यूशन को संशोधित करने के लिए अपनी सुविधाओं के माध्यम से प्रक्रियात्मक या संरचित प्रोग्रामिंग का समर्थन कर सकती है। हालाँकि, सी जैसी भाषाओं ने प्रक्रियात्मक और संरचित प्रोग्रामिंग को अधिक सुविधाजनक बनाने के लिए इन कोडिंग शैलियों के लिए विशिष्ट सिंटैक्स पेश किया। सी # (सी शार्प) भाषा की विशेषताएं, जैसे गुण और इंटरफेस, इसी तरह कोई नया कार्य सक्षम नहीं करते हैं, लेकिन अच्छी प्रोग्रामिंग प्रथाओं को अधिक प्रमुख और प्राकृतिक बनाने के लिए डिज़ाइन किए गए हैं।
कुछ प्रोग्रामर महसूस करते हैं कि ये सुविधाएँ महत्वहीन या तुच्छ हैं। उदाहरण के लिए, एलन पर्लिस ने एक बार घुंघराले ब्रैकेट प्रोग्रामिंग भाषा | ब्रैकेट-सीमांकित भाषाओं के संदर्भ में चुटकी ली, कि सिंटैक्टिक चीनी अर्धविराम के कैंसर का कारण बनती है (प्रोग्रामिंग पर एपिग्राम देखें)।
इसका एक विस्तार है सिंटैक्टिक शुगर#सिंटैक्टिक सैकरिन, या मुफ्त सिंटैक्स जो प्रोग्रामिंग को आसान नहीं बनाता है।[11]
प्रदर्शन तुलना
केवल कुल निर्देश पथ लंबाई में, अनिवार्य शैली में कोडित प्रोग्राम, बिना किसी सबरूटीन्स का उपयोग करते हुए, सबसे कम गिनती होगी। हालाँकि, ऐसे प्रोग्राम का बाइनरी फ़ाइल आकार सबरूटीन्स (कार्यात्मक और प्रक्रियात्मक प्रोग्रामिंग के रूप में) का उपयोग करके कोड किए गए समान प्रोग्राम से बड़ा हो सकता है और संदर्भ के अधिक स्थानीयता को संदर्भित करेगा। गैर-स्थानीय भौतिक निर्देश जो कैशे (कंप्यूटिंग) #ऑपरेशन बढ़ा सकते हैं और निर्देश आधुनिक सेंट्रल प्रोसेसिंग यूनिट में कम्प्यूटेशनल ओवरहेड लाते हैं।
प्रतिमान जो सबरूटीन्स का बड़े पैमाने पर उपयोग करते हैं (कार्यात्मक, प्रक्रियात्मक और वस्तु-उन्मुख सहित) और महत्वपूर्ण इनलाइन विस्तार (कंपाइलर अनुकूलन के माध्यम से इनलाइनिंग) का भी उपयोग नहीं करते हैं, परिणामस्वरूप, सबरूटीन लिंकेज पर कुल संसाधनों के बड़े अंश का उपयोग करेंगे। ऑब्जेक्ट-ओरिएंटेड प्रोग्राम जो इन राज्य परिवर्तनों को समाहित करने के लिए म्यूटेटर विधियों (या सेटर्स) का उपयोग करने के बजाय सीधे प्रोग्राम स्टेट को जानबूझकर नहीं बदलते हैं, प्रत्यक्ष परिणाम के रूप में, अधिक ओवरहेड होंगे। ऐसा इसलिए है क्योंकि संदेश पासिंग अनिवार्य रूप से सबरूटीन कॉल है, लेकिन तीन अतिरिक्त ओवरहेड्स के साथ: गतिशील स्मृति आवंटन, पैरामीटर कॉपी और गतिशील प्रेषण हीप से मेमोरी प्राप्त करने और संदेश पास करने के लिए मापदंडों की प्रतिलिपि बनाने में महत्वपूर्ण संसाधन शामिल हो सकते हैं जो राज्य परिवर्तन के लिए आवश्यक संसाधनों से कहीं अधिक हैं। एक्सेसर्स (या गेटर्स) जो केवल निजी सदस्य चर के मान लौटाते हैं, कुल पथ लंबाई को जोड़ने के बजाय अधिक प्रत्यक्ष असाइनमेंट (या तुलना) का उपयोग करने के बजाय समान संदेश पासिंग सबरूटीन्स पर निर्भर करते हैं।
प्रबंधित कोड
प्रबंधित कोड वातावरण में निष्पादित प्रोग्राम के लिए, जैसे .NET फ्रेमवर्क, कई मुद्दे प्रदर्शन को प्रभावित करते हैं जो प्रोग्रामिंग भाषा प्रतिमान और उपयोग की जाने वाली विभिन्न भाषा सुविधाओं से महत्वपूर्ण रूप से प्रभावित होते हैं।[12]
स्यूडोकोड उदाहरण विभिन्न प्रतिमानों की तुलना
सर्कल के क्षेत्र (πr²) की गणना करने के लिए उपयोग किए जाने वाले अनिवार्य, प्रक्रियात्मक और ऑब्जेक्ट ओरिएंटेड दृष्टिकोणों की स्यूडोकोड तुलना, कोई सबरूटीन इनलाइन विस्तार नहीं, कोई मैक्रो (कंप्यूटर विज्ञान) preprocessor नहीं मानते, अंकगणित पंजीकृत करते हैं, और प्रत्येक निर्देश 'स्टेप' को केवल भारित करते हैं। 1 निर्देश - निर्देश पथ की लंबाई के कच्चे माप के रूप में - नीचे प्रस्तुत किया गया है। निर्देश चरण जो अवधारणात्मक रूप से राज्य परिवर्तन कर रहा है, प्रत्येक मामले में बोल्ड टाइपफेस में हाइलाइट किया गया है। सर्कल के क्षेत्र की गणना करने के लिए उपयोग किए जाने वाले अंकगणितीय संचालन तीनों प्रतिमानों में समान हैं, अंतर यह है कि प्रक्रियात्मक और वस्तु-उन्मुख प्रतिमान उन कार्यों को सबरूटीन कॉल में लपेटते हैं जो गणना को सामान्य और पुन: प्रयोज्य बनाता है। मैक्रो प्रीप्रोसेसर का उपयोग करते हुए विशुद्ध रूप से अनिवार्य प्रोग्राम में समान प्रभाव प्राप्त किया जा सकता है, केवल प्रोग्राम के आकार में वृद्धि (केवल प्रत्येक मैक्रो इनवोकेशन साइट पर) के बिना संबंधित यथानुपात रनटाइम लागत (एन इनवोकेशन के लिए आनुपातिक - जो एक के भीतर स्थित हो सकती है) आंतरिक पाश उदाहरण के लिए)। इसके विपरीत, कंपाइलर द्वारा सबरूटीन इनलाइनिंग प्रक्रियात्मक कार्यक्रमों को आकार में पूरी तरह अनिवार्य कोड के समान कुछ कम कर सकती है। हालाँकि, ऑब्जेक्ट-ओरिएंटेड प्रोग्राम के लिए, इनलाइनिंग के साथ भी, ऑब्जेक्ट-ओरिएंटेड तरीकों द्वारा प्रसंस्करण के लिए संदेशों को अभी भी (तर्कों की प्रतियों से) बनाया जाना चाहिए। कॉल का ओवरहेड, आभासी या अन्यथा, नियंत्रण प्रवाह परिवर्तन का प्रभुत्व नहीं है - लेकिन आसपास के कॉलिंग कन्वेंशन लागतों द्वारा, जैसे फ़ंक्शन प्रस्तावना कोड, स्टैक सेटअप और पैरामीटर (कंप्यूटर प्रोग्रामिंग)#पैरामीटर और तर्क पारित करना[13] (यहाँ देखें[14] अधिक यथार्थवादी निर्देश पथ लंबाई, स्टैक और x86 प्लेटफॉर्म पर कॉल से जुड़ी अन्य लागतों के लिए)। यहां भी देखें[15] एरिक एस रॉबर्ट्स द्वारा स्लाइड प्रस्तुति के लिए ( चर के लिए स्मृति का आवंटन , अध्याय 7)[16] - जावा (प्रोग्रामिंग भाषा) ऑब्जेक्ट-ओरिएंटेड लैंग्वेज में तीन परिमेय संख्याओं को जोड़ते समय स्टैक और हीप मेमोरी के उपयोग का चित्रण।
| अनिवार्य | प्रक्रियात्मक | ऑब्जेक्ट-ओरिएंटेड |
|---|---|---|
load r; 1 r2 = r * r; 2 result = r2 * "3.142"; 3 . . . . . . . . . . . . . . . . . . .... storage ............. result variable constant "3.142" |
area proc(r2,res):
push stack 5
load r2; 6
r3 = r2 * r2; 7
res = r3 * "3.142"; 8
pop stack 9
return; 10
...............................................
main proc:
load r; 1
call area(r,result);
+load p = address of parameter list; 2
+load v = address of subroutine 'area'; 3
+goto v with return; 4
.
.
.
.
.... storage .............
result variable
constant "3.142"
parameter list variable
function pointer (==>area)
stack storage
|
circle.area method(r2):
push stack 7
load r2; 8
r3 = r2 * r2; 9
res = r3 * "3.142"; 10
pop stack 11
return(res); 12,13
...............................................
main proc:
load r; 1
result = circle.area(r);
+allocate heap storage; 2[See 1]
+copy r to message; 3
+load p = address of message; 4
+load v = addr. of method 'circle.area' 5
+goto v with return; 6
.
.
.... storage .............
result variable (assumed pre-allocated)
immutable variable "3.142" (final)
(heap) message variable for circle method call
vtable(==>area)
stack storage
|
प्रक्रियात्मक अमूर्तता और वस्तु-उन्मुख-शैली बहुरूपता के लाभों को ऊपर दिए गए एक छोटे उदाहरण द्वारा खराब रूप से चित्रित किया गया है। यह उदाहरण मुख्य रूप से कुछ आंतरिक प्रदर्शन अंतरों को चित्रित करने के लिए डिज़ाइन किया गया है, अमूर्त या कोड पुन: उपयोग नहीं।
सबरूटीन, मेथड कॉल ओवरहेड
प्रोग्राम में (कहा जाता है) सबरूटीन की उपस्थिति प्रतिमान की परवाह किए बिना प्रोग्राम की कार्यक्षमता के लिए अतिरिक्त योगदान नहीं देती है, लेकिन प्रोग्राम की संरचना और व्यापकता में बहुत योगदान दे सकती है, जिससे इसे लिखना, संशोधित करना और विस्तार करना बहुत आसान हो जाता है।[17] जिस हद तक अलग-अलग प्रतिमान सबरूटीन्स (और उनकी परिणामी मेमोरी आवश्यकताओं) का उपयोग करते हैं, वह संपूर्ण एल्गोरिथ्म के समग्र प्रदर्शन को प्रभावित करता है, हालांकि जैसा कि गाय स्टील ने 1977 के पेपर में बताया, अच्छी तरह से डिज़ाइन की गई प्रोग्रामिंग भाषा के कार्यान्वयन में प्रक्रियात्मक अमूर्तता के लिए बहुत कम ओवरहेड्स हो सकते हैं। (लेकिन अधिकांश कार्यान्वयनों में अफसोस जताते हैं, कि व्यवहार में वे शायद ही कभी इसे प्राप्त करते हैं - बल्कि इस संबंध में विचारहीन या लापरवाह होते हुए)। उसी पेपर में, स्टील ऑटोमेटा-आधारित प्रोग्रामिंग (पूंछ पुनरावर्तन के साथ प्रक्रिया कॉल का उपयोग करके) के लिए विचारित मामला भी बनाता है और निष्कर्ष निकालता है कि हमें प्रक्रिया कॉल के लिए स्वस्थ सम्मान होना चाहिए (क्योंकि वे शक्तिशाली हैं) लेकिन सुझाव दिया कि उन्हें कम से कम उपयोग करें[17]
उपनेमका कॉल की आवृत्ति में:
- प्रक्रियात्मक प्रोग्रामिंग के लिए, कोड की ग्रैन्युलैरिटी # डेटा ग्रैन्युलैरिटी काफी हद तक असतत प्रक्रियाओं या मॉड्यूलर प्रोग्रामिंग की संख्या से निर्धारित होती है।
- कार्यात्मक प्रोग्रामिंग के लिए, पुस्तकालय (कम्प्यूटिंग) सबरूटीन्स के लिए लगातार कॉल आम हैं,[citation needed] लेकिन अक्सर ऑप्टिमाइज़िंग कंपाइलर द्वारा इनलाइन किया जा सकता है
- ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग के लिए, कॉल किए गए मेथड कॉल्स की संख्या भी आंशिक रूप से डेटा संरचनाओं की ग्रैन्युलैरिटी द्वारा निर्धारित की जाती है और इस प्रकार निम्न स्तर की वस्तुओं के लिए कई रीड-ओनली एक्सेस शामिल हो सकते हैं जो इनकैप्सुलेटेड हैं, और इस प्रकार किसी अन्य में एक्सेस करने योग्य नहीं हैं, अधिक प्रत्यक्ष , रास्ता। चूंकि बढ़ी हुई ग्रैन्युलैरिटी अधिक कोड पुन: उपयोग के लिए शर्त है, प्रवृत्ति ठीक-ठाक डेटा संरचनाओं की ओर है, और असतत वस्तुओं (और उनकी विधियों) की संख्या में वृद्धि और इसके परिणामस्वरूप, सबरूटीन कॉल। देव वस्तुओं के निर्माण को सक्रिय रूप से हतोत्साहित किया जाता है। कंस्ट्रक्टर (ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग) भी गिनती में जोड़ते हैं क्योंकि वे सबरूटीन कॉल भी हैं (जब तक कि वे इनलाइन न हों)। जब तक scalability समस्या नहीं बन जाती, तब तक अत्यधिक ग्रैन्युलैरिटी के कारण होने वाली प्रदर्शन समस्याएं स्पष्ट नहीं हो सकती हैं।
- अन्य प्रतिमानों के लिए, जहाँ उपरोक्त प्रतिमानों का मिश्रण नियोजित किया जा सकता है, सबरूटीन का उपयोग कम अनुमानित है।
संदेश और वस्तु भंडारण के लिए गतिशील स्मृति का आवंटन
विशिष्ट रूप से, ऑब्जेक्ट-ओरिएंटेड प्रतिमान में ऑब्जेक्ट निर्माण और संदेश पासिंग दोनों के लिए हीप स्टोरेज से डायनेमिक मेमोरी आवंटन शामिल है। 1994 का बेंचमार्क - डिजिटल उपकरण निगम द्वारा विभिन्न प्रकार के सॉफ़्टवेयर पर संचालित बड़े सी और सी++ प्रोग्राम में मेमोरी एलोकेशन कॉस्ट, इंस्ट्रक्शन-लेवल प्रोफाइलिंग टूल का उपयोग करके मापा गया कि डायनेमिक स्टोरेज आवंटन के लिए कितने निर्देश आवश्यक थे। परिणामों से पता चला कि निष्पादित निर्देशों की सबसे कम निरपेक्ष संख्या औसतन लगभग 50 थी, लेकिन अन्य 611 तक पहुंच गए।[18] मुरली आर. कृष्णन द्वारा हीप: सुख और पीड़ा भी देखें[19] यह बताता है कि ढेर कार्यान्वयन सभी प्लेटफार्मों के लिए सामान्य रहता है, और इसलिए भारी ओवरहेड होता है। आईबीएम के अरुण अयंगर द्वारा 1996 का आईबीएम पेपर स्केलेबिलिटी ऑफ डायनामिक स्टोरेज एलोकेशन एल्गोरिदम [20] विभिन्न डायनेमिक स्टोरेज एल्गोरिदम और उनके संबंधित निर्देश काउंट को प्रदर्शित करता है। यहां तक कि अनुशंसित एमएफएलएफ I एल्गोरिदम (एचएस स्टोन, आरसी 9674) 200 और 400 के बीच की सीमा में निर्देश गणना दिखाता है। उपरोक्त स्यूडोकोड उदाहरण में इस स्मृति आवंटन पथ की लंबाई या स्मृति उपसर्ग ओवरहेड शामिल नहीं है और बाद में संबंधित कचरा शामिल नहीं है। संग्रह ओवरहेड्स। दृढ़ता से सुझाव देते हुए कि हीप आवंटन गैर-तुच्छ कार्य है, गेम डेवलपर जॉन डब्ल्यू रैटक्लिफ द्वारा खुला स्रोत सॉफ्टवेयर माइक्रोएलोकेटर, जिसमें कोड की लगभग 1,000 पंक्तियाँ होती हैं।[21]
गतिशील रूप से प्रेषित संदेश कॉल वी। प्रत्यक्ष प्रक्रिया कॉल ओवरहेड्स
स्टेटिक क्लास पदानुक्रम विश्लेषण का उपयोग करके ऑब्जेक्ट-ओरिएंटेड प्रोग्राम के उनके सार अनुकूलन में,[22] वाशिंगटन विश्वविद्यालय में कंप्यूटर विज्ञान और इंजीनियरिंग विभाग के जेफरी डीन, डेविड ग्रोव और क्रेग चेम्बर्स का दावा है कि वंशानुक्रम और गतिशील रूप से बाध्य संदेशों के भारी उपयोग से कोड को अधिक विस्तार योग्य और पुन: प्रयोज्य बनाने की संभावना है, लेकिन यह गैर-ऑब्जेक्ट-ओरिएंटेड तरीके से लिखे गए समतुल्य लेकिन गैर-विस्तार योग्य प्रोग्राम के सापेक्ष महत्वपूर्ण प्रदर्शन ओवरहेड। कुछ डोमेन में, जैसे कि संरचित ग्राफ़िक्स पैकेज, भारी वस्तु-उन्मुख शैली का उपयोग करके प्रदान किए गए अतिरिक्त लचीलेपन की प्रदर्शन लागत स्वीकार्य है। हालाँकि, अन्य डोमेन में, जैसे कि बुनियादी डेटा संरचना लाइब्रेरी, संख्यात्मक कंप्यूटिंग पैकेज, रेंडरिंग लाइब्रेरी और ट्रेस-संचालित सिमुलेशन फ्रेमवर्क, संदेश पास करने की लागत बहुत अधिक हो सकती है, जिससे प्रोग्रामर को "हॉट" में ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग से बचने के लिए मजबूर होना पड़ता है। स्पॉट ”उनके आवेदन के।
वस्तुओं को क्रमबद्ध करना
क्रमबद्धता ऑब्जेक्ट (कंप्यूटर साइंस) को सिस्टम से दूसरे सिस्टम में पास करते समय बड़े ओवरहेड्स लगाता है, खासकर जब ट्रांसफर मानव-पठनीय प्रारूपों जैसे एक्सटेंसिबल मार्कअप लैंग्वेज (एक्सएमएल) और जावास्क्रिप्ट ऑब्जेक्ट नोटेशन (जेएसओएन) में होता है। यह गैर-ऑब्जेक्ट उन्मुख डेटा के लिए कॉम्पैक्ट बाइनरी प्रारूपों के विपरीत है। ऑब्जेक्ट के डेटा मान और इसकी विशेषताओं के एन्कोडिंग और डिकोडिंग दोनों क्रमबद्ध प्रक्रिया में शामिल हैं, जिसमें विरासत, एनकैप्सुलेटिंग और डेटा छिपाने जैसे जटिल मुद्दों के बारे में जागरूकता भी शामिल है।
समानांतर कंप्यूटिंग
मार्च 2011 में कार्नेगी-मेलन विश्वविद्यालय के प्रोफेसर रॉबर्ट हार्पर (कंप्यूटर वैज्ञानिक) ने लिखा: इस सेमेस्टर डैन लिकाटा और मैं प्रथम वर्ष के संभावित सीएस मेजर्स के लिए कार्यात्मक प्रोग्रामिंग पर नया पाठ्यक्रम सह-शिक्षण दे रहे हैं। परिचयात्मक पाठ्यक्रम, क्योंकि यह अपनी प्रकृति से मॉड्यूलर और विरोधी समानांतर दोनों है, और इसलिए आधुनिक सीएस पाठ्यक्रम के लिए अनुपयुक्त है। उन छात्रों के लिए जो इस विषय का अध्ययन करना चाहते हैं, द्वितीय स्तर पर वस्तु-उन्मुख डिजाइन पद्धति पर प्रस्तावित नया पाठ्यक्रम पेश किया जाएगा।[23]
यह भी देखें
- प्रोग्रामिंग भाषाओं की तुलना
- प्रोग्रामिंग भाषाओं की तुलना (मूल निर्देश)
- ग्रैन्युलैरिटी # कम्प्यूटिंग
- संदेश देना
- सबरूटीन
संदर्भ
- ↑ "Programming paradigms: What are the principles of programming?". IONOS. IONOS. Retrieved 30 May 2022.
- ↑ "Archived copy" (PDF). Archived from the original (PDF) on 2017-02-02. Retrieved 2015-12-18.
{{cite web}}: CS1 maint: archived copy as title (link) - ↑ "Functional programming C#". August 2020. Retrieved 2015-08-14.
- ↑ Ruiz, Cedric (May 2014). "Functional CoffeeScript for the impatient". Blog de Cedric Ruiz. Cedric Ruiz. Retrieved 2015-08-09.
- ↑ "Functional programming · Advanced R".
- ↑ Shelly, Asaf (2008-08-22). "Flaws of Object-oriented Modeling". Intel Software Network. Retrieved 2010-07-04.
- ↑ Yegge, Steve (2006-03-30). "Execution in the Kingdom of Nouns". steve-yegge.blogspot.com. Retrieved 2010-07-03.
- ↑ "Data-Oriented Design (Or Why You Might be Shooting Yourself in the Foot with OOP) – Games from within".
- ↑ Crockford, Douglas. "JavaScript: The World's Most Misunderstood Programming Language". crockford.com.
- ↑ Crockford, Douglas. "Private Members in JavaScript". crockford.com.
- ↑ "The Jargon File v4.4.7: "syntactic sugar"".
- ↑ Gray, Jan (June 2003). "Writing Faster Managed Code: Know What Things Cost". MSDN. Microsoft.
- ↑ "कॉल की सही कीमत". wordpress.com. 2008-12-30.
- ↑ "X86 Disassembly/Functions and Stack Frames - Wikibooks, open books for an open world".
- ↑ Roberts, Eric S. (2008). "Art and Science of Java; Chapter 7: Objects and Memory". Stanford University. Archived from the original on 2011-06-06. Retrieved 2010-05-17.
- ↑ Roberts, Eric S. (2008). जावा की कला और विज्ञान. Addison-Wesley. ISBN 978-0-321-48612-7. Archived from the original on 2011-06-06. Retrieved 2010-05-17.
- ↑ 17.0 17.1 Guy Lewis Steele, Jr. "Debunking the 'Expensive Procedure Call' Myth, or, Procedure Call Implementations Considered Harmful, or, Lambda: The Ultimate GOTO". MIT AI Lab. AI Lab Memo AIM-443. October 1977. [1] Archived 2009-12-29 at the Wayback Machine[2][3]
- ↑ Detlefs, David; Dosser, Al; Zorn, Benjamin (June 1994). "Memory Allocation Costs in Large C and C++ Programs; Page 532". Software: Practice and Experience. 24 (6): 527–542. CiteSeerX 10.1.1.30.3073. doi:10.1002/spe.4380240602. S2CID 14214110.
- ↑ Krishnan, Murali R. (February 1999). "Heap: Pleasures and pains". microsoft.com.
- ↑ "गतिशील भंडारण आवंटन एल्गोरिदम की मापनीयता". 1996. CiteSeerX 10.1.1.3.3759.
{{cite journal}}: Cite journal requires|journal=(help) - ↑ "माइक्रोआवंटक.एच". Google Code. Retrieved 2012-01-29.
- ↑ Dean, Jeffrey; Grove, David; Chambers, Craig (1995). "Optimization of Object-Oriented Programs Using Static Class Hierarchy Analysis". ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग. Lecture Notes in Computer Science. Vol. 952. University of Washington. pp. 77–101. CiteSeerX 10.1.1.117.2420. doi:10.1007/3-540-49538-X_5. ISBN 978-3-540-60160-9.
- ↑ Teaching FP to Freshmen, from Harper's blog about teaching introductory computer science.[4]
अग्रिम पठन
- "A Memory Allocator" by Doug Lea
- "Dynamic Memory Allocation and Linked Data Structures" by (Scottish Qualifications Authority)
- "Inside A Storage Allocator" by Dr. Newcomer Ph.D
बाहरी संबंध
- Comparing Programming Paradigms by Dr Rachel Harrison and Mr Lins Samaraweera
- Comparing Programming Paradigms: an Evaluation of Functional and Object-Oriented Programs by Harrison, R., Samaraweera, L. G., Dobie, M. R. and Lewis, P. H. (1996) pp. 247–254. ISSN 0268-6961
- "The principal programming paradigms" By Peter Van Roy
- "Concepts, Techniques, and Models of Computer Programming" (2004) by Peter Van Roy & Seif Haridi, ISBN 0-262-22069-5
- The True Cost of Calls- from "Harder, Better, Faster, Stronger" blog by computer scientist Steven Pigeon
