जावा-परफॉरमेंस: Difference between revisions

Latest revision as of 13:58, 7 July 2023

सॉफ्टवेयर विकास में, जावा (प्रोग्रामिंग भाषा) को ऐतिहासिक रूप से C (प्रोग्रामिंग भाषा) और C++ जैसी सबसे तेज तृतीय पीढ़ी वर्ग पद्धति भाषाओं की तुलना में धीमी माना जाता था।^[1] मुख्य कारण एक अलग भाषा प्रारुप है, जहां संकलन के बाद, जावा प्रोग्राम पर सीधे कंप्यूटर के केंद्रीय प्रोसेसर इकाई पर मूल कोड के रूप में चलने के बजाय जावा वर्चुअल मशीन (जेवीएम) पर चलते हैं, जैसा कि C और C++ प्रोग्रामों के रूप में होता है। प्रदर्शन प्रसंग का विषय था क्योंकि 1990 के दशक के अंत और 2000 के दशक की प्रारम्भ में भाषा के तेजी से लोकप्रिय होने के बाद जावा में बहुत से व्यावसायिक सॉफ्टवेयर लिखे गए हैं।

1990 के दशक के अंत से,जावा प्रोग्राम के निष्पादन गति में जस्ट-इन-टाइम कंपाइलेशन (जेआईटी) (जावा 1.1 के लिए 1997 में),^[2]^[3]^[4] बेहतर कोड विश्लेषण का समर्थन करने वाली भाषा सुविधाओं के परिचय के माध्यम से जावा प्रोग्रामों की निष्पादन गति में काफी सुधार हुआ। जेवीएम में विश्लेषण, जावा बाइटकोड के हार्डवेयर निष्पादन, जैसे कि एआरएम के जज़ेल द्वारा प्रस्तुत किया गया, अनुकूलन को भी (जैसे हॉटस्पॉट 2000 में सन के जेवीएम के लिए अकरण बन गया) और महत्वपूर्ण प्रदर्शन सुधार प्रस्तुत करने के लिए खोज की गई थी।

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

वर्चूअल मशीन अनुकूलन पद्धतियाँ

एकाधिक ऑप्टिमाइज़ेशन ने समय के साथ जेवीएम के प्रदर्शन में सुधार किया है। यद्यपि, जावा अधिकांशतः उन्हें सफलतापूर्वक लागू करने वाली पहली वर्चूअल मशीन थी, लेकिन उनका उपयोग अधिकांशतः अन्य समरूप प्लेटफार्मों में भी किया जाता है।

जस्ट-इन-टाइम संकलन

प्रारंभिक जेवीएम ने हमेशा जावा बाइटकोड की व्याख्या की। औसत अनुप्रयोगों में जावा बनाम C के लिए कारक 10 और 20 के बीच इसका एक बड़ा प्रदर्शन दंड था।^[5] [5] इससे निपटने के लिए, जावा 1.1 में जस्ट-इन-टाइम (जेआईटी) संकलक प्रस्तुत किया गया था। संकलन की उच्च लागत के कारण, जावा 1.2 में हॉटस्पॉट नामक एक अतिरिक्त प्रणाली को प्रस्तुत किया गया था और इसे जावा 1.3 में अकरण बना दिया गया था। इस रूपरेखा का उपयोग करते हुए, जावा वर्चुअल मशीन लगातार हॉट स्पॉट के लिए प्रोग्राम के प्रदर्शन का विश्लेषण करती है। जो बार-बार निष्पादित किए जाते हैं या बार-बार. ये तब अनुकूलित करने के लिए लक्षित होते हैं, जिससे कम प्रदर्शन-महत्वपूर्ण कोड के लिए न्यूनतम ओवरहेड के साथ उच्च प्रदर्शन निष्पादन होता है।^[6]^[7] कुछ बेंचमार्क इस माध्यम से 10 गुना गति प्राप्त करते हैं।^[8]यद्यपि, समय की कमी के कारण, संकलक प्रोग्राम को पूरी तरह से अनुकूलित नहीं कर सकता है, और इस प्रकार परिणामी प्रोग्राम मूल कोड विकल्पों की तुलना में धीमा होता है।^[9]^[10]

अनुकूली अनुकूलन

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

हॉटस्पॉट जैसी जावा वर्चुअल मशीन भी पूर्व में जेआईटीईडी कोड को अनुकूलित कर सकती है। यह अग्रेसिव (और संभावित रूप से असुरक्षित) अनुकूलन करने की अनुमति देता है, जबकि बाद में कोड को अनुकूलित करने और सुरक्षित पथ पर वापस आने में सक्षम होने के लिए।^[11]^[12]

कचरा संग्रह

1.0 और 1.1 जावा वर्चुअल मशीन (जेवीएम) ने एक मार्क-स्वीप संग्राहक का उपयोग किया, जो कचरा संग्रह के बाद ढेर को खंडित कर सकता था। जावा 1.2 से प्रारम्भ होकर, जेवीएम एक पीढ़ीगत संग्राहक में बदल गया, जिसका बेहतर विखंडन व्यवहार है।^[13] आधुनिक जेवीएम विभिन्न प्रकार के तरीकों का उपयोग करते हैं जिन्होंने कचरा संग्रह (कंप्यूटर विज्ञान प्रदर्शन में और सुधार किया है। ^[14]

अन्य अनुकूलन विधियां

संकुचित उफ़

32-बिट संदर्भों के साथ संपीड़ित ऊप्स जावा 5.0+ को 32 जीबी तक के संग्रह को संबोधित करने की अनुमति देता है। जावा व्यक्तिगत बाइट्स तक पहुँच का समर्थन नहीं करता है, केवल विषय जो अकरण रूप से 8 बाइट संरेखित हैं। इस कारण से, संग्रह संदर्भ के सबसे कम 3 बिट्स हमेशा 0 होंगे। 32-बिट संदर्भों के 8 बाइट खंडोंों के संकल्प को कम करके, पता योग्य स्थान को 32 जीबी तक बढ़ाया जा सकता है। यह 64-बिट संदर्भों का उपयोग करने की तुलना में मेमोरी उपयोग को महत्वपूर्ण रूप से कम करता है क्योंकि जावा C++ जैसी कुछ भाषाओं की तुलना में संदर्भों का अधिक उपयोग करता है। जावा 8 32-बिट संदर्भों के साथ 64 GB तक समर्थन करने के लिए 16-बाइट संरेखण जैसे बड़े संरेखण का समर्थन करता है।

विभाजन बाइटकोड सत्यापन

एक वर्ग (कंप्यूटर विज्ञान) को क्रियान्वित करने से पहले, सन जेवीएम अपने जावा बाइटकोड को सत्यापित करता है (बायटेकोड सत्यापनकर्ता देखें)। यह सत्यापन लज़ीली से किया जाता है: वर्गों के बायटेकोड केवल तभी लोड और सत्यापित होते हैं जब विशिष्ट वर्ग को लोड किया जाता है और उपयोग के लिए तैयार किया जाता है, न कि प्रोग्राम की प्रारम्भ में। यद्यपि, जावा वर्ग पुस्तकालय भी नियमित जावा वर्ग हैं, जब उनका उपयोग किया जाता है, तो उन्हें भी लोड किया जाना चाहिए, जिसका अर्थ है कि जावा प्रोग्राम का प्रारंभ समय अधिकांशतः C ++ प्रोग्राम की तुलना में अधिक लंबा होता है, उदाहरण के लिए।

विभाजन-समय सत्यापन नाम की विधि, जिसे पहली बार जावा प्लेटफॉर्म, माइक्रो एडिशन (जे2एमई) में प्रस्तुत किया गया था, जावा संस्करण 6 के बाद से जावा संस्करण इतिहास में उपयोग किया जाता है। यह जावा बाइटकोड के सत्यापन को दो चरणों में विभाजित करता है:^[15]

प्रारुप-समय - जब स्रोत से बाइटकोड तक एक वर्ग का संकलन किया जाता है
कार्यावधि - जब किसी वर्ग को भारण किया जाता है।

व्यवहार में यह विधि ज्ञान को प्रग्रहण करके काम करती है कि जावा संकलक में वर्ग प्रवाह है की जानकारी का एक सारांश के साथ संकलित विधि बायटेकोड एनोटेट करता है। यह कार्यावधि सत्यापन को पर्याप्त रूप से कम जटिल नहीं बनाता है, लेकिन कुछ शॉर्टकट की अनुमति देता है।

एस्केप एनालिसिस और लॉक कोर्सनिंग

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

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

जैसा कि जावा पुस्तकालय को यह नहीं पता है कि एक से अधिक थ्रेड्स द्वारा कौन सी विधियों का उपयोग किया जाएगा, मानक पुस्तकालय हमेशा मल्टीथ्रेडेड वातावरण में आवश्यकता पड़ने पर खंडों को लॉक कर देती है।

जावा 6 से पहले, वर्चुअल मशीन हमेशा प्रोग्राम द्वारा पूछे जाने पर विषय्स और खंडों को अवरोधित कर देती थी, भले ही किसी विषय को एक साथ दो अलग-अलग थ्रेड्स द्वारा संशोधित किए जाने का कोई जोखिम न हो। उदाहरण के लिए, इस स्थिति में, प्रत्येक ऐड संचालन से पहले एक स्थानीय वेक्टरलॉक किया गया था ताकि यह सुनिश्चित किया जा सके कि इसे अन्य थ्रेड्स द्वारा संशोधित नहीं किया जाएगा (वेक्टर सिंक्रनाइज़ है), लेकिन क्योंकि यह विधि के लिए सख्ती से स्थानीय है, यह अनावश्यक है: जावा 6 से पहले, आभासी मशीन हमेशा प्रोग्राम द्वारा मांगे जाने पर वस्तुओं और खंडों को अवरोधित करती है, भले ही एक बार में दो भिन्न थ्रेड द्वारा किसी वस्तु को संशोधित किए जाने का कोई जोखिम न हो. उदाहरण के लिए, इस स्थिति में, एक स्थानीय वेक्टर प्रत्येक जोड़े कार्रवाई से पहले यह सुनिश्चित करने के लिए लॉक कर दिया गया था कि इसे अन्य थ्रेड द्वारा संशोधित नहीं किया जाएगा (वेक्टर सिंक्रनाइज़ किया गया है), क्योंकि यह विधि के लिए पूरी तरह से स्थानीय है इसलिए यह अनावश्यक है:

public String getNames() {
     final Vector<String> v = new Vector<>();
     v.add("Me");
     v.add("You");
     v.add("Her");
     return v.toString();
}

जावा 6 कोड खंडों और विषय से प्रारम्भ होकर,केवल आवश्यकता होने पर ही लॉक हो जाते हैं,,^[16] इसलिए उपरोक्त स्थिति में, वर्चुअल मशीन वेक्टर विषय को बिल्कुल भी लॉक नहीं करेगी।

संस्करण 6u23 के बाद से, जावा में एस्केप विश्लेषण के लिए समर्थन सम्मिलित है।^[17]

आवंटन सुधार दर्ज करें

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

सन के जेडीके 6 में रजिस्टर आवंटन का एक अनुकूलन प्रस्तुत किया गया था;^[18] यह तब खंडों में एक ही रजिस्टर का उपयोग करना संभव था (जब लागू हो), मेमोरी तक पहुंच को कम करना। इसके कारण कुछ बेंचमार्क में लगभग 60 प्रतिशत की वृद्धि दर्ज की गई। ^[19]

वर्ग डेटा शेयरिंग

वर्ग डेटा शेयरिंग (जिसे सन द्वारा सीडीएस कहा जाता है) एक तंत्र है जो जावा अनुप्रयोगों के लिए स्टार्टअप समय को कम करता है, और मेमोरी फुटप्रिंट को भी कम करता है। जब जावा क्रम पर्यावरण स्थापित होता है, तो इंस्टॉलर प्रणालियों जेएआर फ़ाइल से वर्गों का एक सेट लोड करता है (जेएआर फ़ाइल जिसमें सभी जावा वर्ग पुस्तकालय होती है, जिसे आरटी.जेएआर कहा जाता है) निजी आंतरिक प्रतिनिधित्व में, और उस प्रतिनिधित्व को फ़ाइल में डंप करता है, जिसे "साझा संग्रह" कहा जाता है। बाद के जेवीएम विक्रमों के दौरान, यह साझा संग्रह मेमोरी-मैप्ड है, उन वर्गों को लोड करने की लागत को बचाता है और इन वर्गों के लिए जेवीएम के मेटाडेटा को एकाधिक जेवीएम प्रक्रियाओं के बीच साझा करने की अनुमति देता है।^[20]

छोटे प्रोग्रामों के लिए स्टार्ट-अप समय में संबंधित सुधार अधिक स्पष्ट होता है।^[21]

प्रदर्शन में सुधार का इतिहास

यहां सूचीबद्ध सुधारों के अलावा, जावा के प्रत्येक रिलीज ने जेवीएम और जावा विनियोग प्रोग्रामिंग इंटरफेस (एपीआई) में एकाधिक प्रदर्शन सुधार प्रस्तुत किए।

जेडीके 1.1.6: पहला जस्ट-इन-टाइम संकलन (नॉर्टनलाइफ लॉक' जेआईटी-संकलक)^[2]^[22]

जे2एसई 1.2: कचरा संग्रहण (कंप्यूटर विज्ञान) जनरेशनल जीसी (उर्फ एपेमेरल जीसी) का उपयोग।

जे2एसई 1.3:हॉटस्पॉट (वर्चुअल मशीन) द्वारा जस्ट-इन-टाइम कंपाइलिंग।

जे2एसई 1.4: 1.3 और 1.4 संस्करणों के बीच प्रदर्शन सुधारों के सन ओवरव्यू के लिए यहां देखें,।

जावा एसई 5.0: वर्ग डेटा साझाकरण^[23]

जावा एसई 6

विभाजित बायटेकोड सत्यापन
एस्केप विश्लेषण और लॉक कोर्सनिंग
आवंटन में सुधार दर्ज करें

अन्य सुधार:

जावा ओपनजीएल जावा 2डी पाइपलाइन गति में सुधार^[24]
जावा 2डी प्रदर्शन में भी जावा 6 में काफी सुधार हुआ है^[25]

'जावा 5 और जावा 6 के बीच प्रदर्शन में सुधार का सन ओवरव्यू' भी देखें।^[26]

जावा एसई 6 अपडेट 10

जावा त्वरित स्टार्टर डिस्क कैश पर ओएस स्टार्टअप पर जेआरई डेटा के भाग को पहले से लोड करके विनियोग स्टार्ट-अप समय को कम करता है।^[27]
जेआरई स्थापित नहीं होने पर वेब से एक्सेस किए गए विनियोग को निष्पादित करने के लिए आवश्यक प्लेटफॉर्म के भाग अब पहले डाउनलोड किए जाते हैं। पूर्ण जेआरई 12 एमबी है, एक सामान्य स्विंग विनियोग को प्रारम्भ करने के लिए केवल 4 एमबी डाउनलोड करने की आवश्यकता है। इसके बाद बाकी हिस्सों को बैकग्राउंड में डाउनलोड किया जाता है।^[28]
अकरण रूप से का व्यापक रूप से उपयोग करके पर ग्राफ़िक्स प्रदर्शन में सुधार हुआ है, और जटिल जावा 2डी संचालन में तेजी लाने के लिए (जीपीयू) का उपयोग करें।
अकरण रूप से डायरेक्ट 3डी का व्यापक रूप से उपयोग करके विंडोज पर ग्राफिक्स के प्रदर्शन में सुधार हुआ है,^[29] और जटिल जावा 2डी संचालन में तेजी लाने के लिए ग्राफ़िक्स प्रोसेसिंग यूनिट (जीपीयू) पर शेडर्स का उपयोग करें।^[30]

जावा 7

जावा 7 के लिए एकाधिक प्रदर्शन सुधार जारी किए गए हैं: जावा 6 या जावा 7 के अपडेट के लिए भविष्य के प्रदर्शन सुधारों की योजना बनाई गई है:^[31]

वर्तमान में दा विंची मशीन (मल्टी लैंग्वेज वर्चुअल मशीन) पर किए गए प्रोटोटाइप कार्य के बाद गतिशील प्रोग्रामिंग भाषाओं के लिए जेवीएम समर्थन प्रदान करें,^[32]
मल्टी कोर प्रोसेसर पर समांतर कंप्यूटिंग प्रबंधित करके मौजूदा समवर्ती पुस्तकालय को बढ़ाएं,^[33]^[34]
जेवीएम को एक ही सत्र में क्लाइंट और सर्वर जेआईटी संकलक्स दोनों का उपयोग करने की अनुमति दें, जिसे टियरड कंपाइलिंग कहा जाता है:^[35]
- क्लाइंट का उपयोग स्टार्टअप पर किया जाएगा (क्योंकि यह स्टार्टअप पर और छोटे अनुप्रयोगों के लिए अच्छा है),
- सर्वर का उपयोग विनियोग के लंबे समय तक चलने के लिए किया जाएगा (क्योंकि यह इसके लिए क्लाइंट संकलक से बेहतर प्रदर्शन करता है)।
मौजूदा समवर्ती कम-विराम कचरा संग्राहक (जिसे समवर्ती मार्क-स्वीप (सीएमएस) संग्राहक भी कहा जाता है) को एक नए संग्राहक द्वारा प्रतिस्थापित किया जाता है जिसे कचरा पहले (जी1) कहा जाता है ताकि समय के साथ लगातार ठहराव सुनिश्चित हो सके।^[36]^[37] .

अन्य भाषाओं की तुलना

जावा प्रोग्राम के प्रदर्शन की वस्तुनिष्ठ तुलना और एक अन्य भाषा में लिखे गए समकक्ष जैसे कि C++ को सावधानीपूर्वक और सोच-समझकर निर्मित बेंचमार्क की आवश्यकता होती है जो समान कार्यों को पूरा करने वाले प्रोग्रामों की तुलना करता है। जावा के बाईटकोड संकलक का लक्ष्य प्लेटफॉर्म जावा प्लेटफॉर्म है, और बायटेकोड को या तो जेवीएम द्वारा मशीन कोड में व्याख्या या संकलित किया जाता है। अन्य संकलक लगभग हमेशा एक विशिष्ट हार्डवेयर और सॉफ्टवेयर प्लेटफॉर्म को लक्षित करते हैं, मशीन कोड का उत्पादन करते हैं जो निष्पादन के दौरान वस्तुतः अपरिवर्तित रहेगा। इन दो अलग-अलग दृष्टिकोणों से बहुत भिन्न और कठिन-से-तुलना वाले परिदृश्य उत्पन्न होते हैं: स्थिर बनाम गतिशील संकलन और पुनर्संकलन, कार्यावधि वातावरण और अन्य के बारे में सटीक जानकारी की उपलब्धता।

जावा वर्चुअल मशीन द्वारा जावा कोअधिकांशतः कार्यावधि पर समय-समय पर संकलित किया जाता है, लेकिन C++ के रूप में भी समय-समय पर संकलित किया जा सकता है। जब सही समय पर संकलित किया जाता है, द कंप्यूटर भाषा बेंचमार्क गेम के माइक्रो-बेंचमार्क इसके प्रदर्शन के बारे में निम्नलिखित संकेत देते हैं:^[38]

C (प्रोग्रामिंग भाषा) या C++ जैसे संकलित भाषाओं से धीमी,^[39]
अन्य समय-समय पर संकलित भाषाओं जैसे C,^[40] के समान
पर्ल, रूबी (प्रोग्रामिंग भाषा), पीएचपी और पायथन जैसे प्रभावी नेटिव-कोड संकलक (जेआईटी या एओटी) के बिना भाषाओं की तुलना में बहुत तेज।^[41]

प्रोग्राम की गति

बेंचमार्क अधिकांशतः छोटे संख्यात्मक रूप से गहन प्रोग्रामों के प्रदर्शन को मापते हैं। कुछ दुर्लभ वास्तविक जीवन के प्रोग्रामों में, जावा C से बेहतर प्रदर्शन करता है। एक उदाहरण जेक2 (मूल जीपीएल सी कोड का अनुवाद करके जावा में लिखा गया क्वेक II का एक क्लोन) का बेंचमार्क है। जावा 5.0 संस्करण अपने सी समकक्ष की तुलना में कुछ हार्डवेयर विन्यासों में बेहतर प्रदर्शन करता है।^[42]यद्यपि यह निर्दिष्ट नहीं किया गया है कि डेटा को कैसे मापा गया था (उदाहरण के लिए यदि 1997 में संकलित मूल क्वेक II निष्पादन योग्य का उपयोग किया गया था, जिसे खराब माना जा सकता है क्योंकि वर्तमान सी संकलक क्वेक के लिए बेहतर अनुकूलन प्राप्त कर सकते हैं), यह नोट करता है कि कैसे समान जावा स्रोत कोड केवल वीएम को अपडेट करने से गति में भारी वृद्धि हो सकती है, जो 100% स्थिर दृष्टिकोण के साथ प्राप्त करना असंभव है।

अन्य प्रोग्रामों के लिए, C++ समकक्ष जावा समकक्ष से काफी तेजी से चला सकता है, और सामान्यतः करता है। 2011 में गूगल द्वारा किए गए बेंचमार्क ने C++ और जावा के बीच एक कारक 10 को दिखाया।^[43] दूसरे चरम पर, एक 3डी मॉडलिंग एल्गोरिदम के साथ 2012 में किए गए एक शैक्षणिक बेंचमार्क ने जावा 6 जेवीएम को विंडोज के तहत C++ की तुलना में 1.09 से 1.91 गुना धीमा दिखाया।^[44]

कुछ अनुकूलन जो जावा और समान भाषाओं में संभव हैं, कुछ परिस्थितियों में C++ में संभव नहीं हो सकते हैं:

सी-शैली सूचक प्रयोग उन भाषाओं में अनुकूलन में बाधा डाल सकता है जो सूचकों का समर्थन करती हैं,
एस्केप एनालिसिस विधियों का उपयोग C++ में सीमित है, उदाहरण के लिए, क्योंकि एक C++ संकलक हमेशा यह नहीं जानता है कि संकेतक के कारण कोड के दिए गए खंडों में विषय को संशोधित किया जाएगा या नहीं,^{[note 1]}
जावा C++ के अतिरिक्त वर्चुअल-तालिका लुक-अप के कारण व्युत्पन्न वर्चुअल विधियों तक तेजी से पहुंच प्राप्त कर सकता है। यद्यपि, C++ में गैर-वर्चूअल विधियां वी-तालिका प्रदर्शन बाधाओं से पीड़ित नहीं होती हैं, और इस प्रकार जावा के समान प्रदर्शन प्रदर्शित करती हैं।

जेवीएम प्रोसेसर विशिष्ट अनुकूलन या अपंक्तिबद्ध विस्तार का प्रदर्शन करने में सक्षम है। और, पहले से संकलित या अपंक्तिबद्ध किए गए कोड को डी-अनुकूलित करने की क्षमता कभी-कभी इसे द्वारा निष्पादित किए गए कोड की तुलना में अधिक आक्रामक अनुकूलन निष्पादित करने की अनुमति देती है^[45]^[46]

जावा और C++ के बीच माइक्रोबेंचमार्क) के परिणाम अत्यधिक निर्भर करते हैं कि किस संचालन की तुलना की जाती है। उदाहरण के लिए, जावा 5.0 के साथ तुलना करते समय:

32 और 64 बिट अंकगणितीय संचालन,^[47]^[48] इनपुट/आउटपुट|फ़ाइल I/O^[49] और अपवाद हैंडलिंग,^[50] तुलनीय C++ प्रोग्राम के समान प्रदर्शन है
सरणियाँ^[51] के संचालन का प्रदर्शन C में बेहतर है।
C में त्रिकोणमितीय फलनों का प्रदर्शन काफी बेहतर है।^[52]

टिप्पणियाँ

↑ Contention of this nature can be alleviated in C++ programs at the source code level by employing advanced methods such as custom allocators, exploiting precisely the kind of low-level coding complexity that Java was designed to conceal and encapsulate; however, this approach is rarely practical if not adopted (or at least anticipated) while the program remains under primary development.

बहु-कोर प्रदर्शन

बहु-कोर प्रणालियों पर जावा अनुप्रयोगों की मापनीयता और प्रदर्शन वस्तु आवंटन दर द्वारा सीमित है। इस प्रभाव को कभी-कभी "आवंटन दीवार" कहा जाता है।^[53]यद्यपि, व्यवहार में, आधुनिक कचरा संग्राहक एल्गोरिदम कचरा संग्रह करने के लिए एकाधिक कोर का उपयोग करते हैं, जो कुछ हद तक इस समस्या को कम करता है। कुछ कचरा संग्राहक प्रति सेकंड एक गीगाबाइट से अधिक की आवंटन दर को बनाए रखने की सूचना देते हैं,^[54] और जावा-आधारित प्रणालियों मौजूद हैं जिन्हें एकाधिक सैकड़ों सीपीयू कोर और ढेर के आकार को एकाधिक सौ जीबी तक बढ़ाने में कोई समस्या नहीं है।^[55]

जावा में स्वचालित मेमोरी प्रबंधन लॉकलेस और अपरिवर्तनीय डेटा संरचनाओं के कुशल उपयोग की अनुमति देता है जो किसी प्रकार के कचरा संग्रह के बिना लागू करने के लिए अत्यंत कठिन या कभी-कभी असंभव हैं।^{[citation needed]} जावा अपने मानक पुस्तकालय में ऐसी एकाधिक उच्च-स्तरीय संरचनाएं प्रदान करता है। जावा.यूटीआईआई.कन्करन्ट पैकेज में, जबकि C या C++ जैसी उच्च प्रदर्शन प्रणालियों के लिए ऐतिहासिक रूप से उपयोग की जाने वाली एकाधिक भाषाओं में अभी भी उनकी कमी है।^{[citation needed]}

स्टार्टअप समय

जावा स्टार्टअप समय अधिकांशतः C, C++, पर्ल या पायथन सहित एकाधिक भाषाओं की तुलना में बहुत धीमा होता है, क्योंकि उपयोग किए जाने से पहले एकाधिक वर्गों (और सबसे पहले प्लेटफ़ॉर्म वर्ग पुस्तकालय से सभी वर्गों) को लोड किया जाना चाहिए।

विंडोज मशीन पर चलने वाले छोटे प्रोग्रामों के समान लोकप्रिय कार्यावधि के साथ तुलना करने पर, स्टार्टअप का समय मोनो के समान और नेट की तुलना में थोड़ा धीमा प्रतीत होता है।^[56]

ऐसा लगता है कि स्टार्टअप का अधिकांश समय जेवीएम प्रारंभीकरण या वर्ग भारण के बजाय इनपुट-आउटपुट (IO) सीमित संचालन के कारण होता है (अकेले rt.जेएआर वर्ग डेटा फ़ाइल 40 एमबी है और जेवीएम को इस बड़ी फ़ाइल में बहुत अधिक डेटा की तलाश करनी चाहिए)^[27] कुछ परीक्षणों से पता चला है कि यद्यपि नई विभाजन बायटेकोड सत्यापन विधि ने वर्ग भारण में लगभग 40% की वृद्धि की, इसने केवल बड़े प्रोग्रामों के लिए केवल 5% स्टार्टअप सुधार का संपादित किया।^[57]

एक छोटे से सुधार के बावजूद, यह छोटे प्रोग्रामों में अधिक दिखाई देता है जो एक साधारण परिचालन करते हैं और फिर बाहर निकल जाते हैं, क्योंकि जावा प्लेटफॉर्म डेटा भारण वास्तविक प्रोग्राम के संचालन के एकाधिक गुना लोड का प्रतिनिधित्व कर सकता है।

जावा एसई 6 अपडेट 10 से प्रारम्भ होकर, सन जेआरई एक त्वरित स्टार्टर के साथ आता है जो डिस्क के बजाय डिस्क कैश से डेटा प्राप्त करने के लिए ओएस स्टार्टअप पर वर्ग डेटा पहले से लोड करता है।

एक्सेलसियर जेट दूसरी तरफ से समस्या का समाधान करता है। इसका स्टार्टअप ऑप्टिमाइज़र उस डेटा की मात्रा को कम करता है जिसे डिस्क से विनियोग स्टार्टअप पर पढ़ा जाना चाहिए, और पढ़ने को अधिक अनुक्रमिक बनाता है।

नवंबर 2004 में, नेलगन, "क्लाइंट, प्रोटोकॉल, और जेवीएम स्टार्टअप के ऊपर सर्वर जो आदेश पंक्ति से जावा प्रोग्राम चलाने के लिए" सार्वजनिक रूप से जारी किया गया था।'^[58] बिना जेवीएम स्टार्टअप ओवरहेड के एक या एक से अधिक जावा विनियोग चलाने के लिए पहली बार स्क्रिप्ट (कंप्यूटिंग) के लिए एक जेवीएम को डेमन (कंप्यूटिंग) के रूप में उपयोग करने का विकल्प प्रस्तुत करना। नेलगुन डेमन असुरक्षित है: "सभी प्रोग्राम सर्वर के समान अनुमतियों के साथ चलाए जाते हैं"। जहाँ बहु-उपयोगकर्ता सुरक्षा की आवश्यकता होती है, विशेष सावधानियों के बिना नेलगन अनुपयुक्त है। लिपियों जहां प्रति-अनुप्रयोग जेवीएम स्टार्टअप संसाधन उपयोग पर हावी है, परिमाण कार्यावधि प्रदर्शन में सुधार के एक से दो क्रम देखें।^[59]

मेमोरी उपयोग

जावा मेमोरी का उपयोग C++ के मेमोरी उपयोग से काफी अधिक है क्योंकि:

जावा में प्रत्येक वस्तु के लिए 8 बाइट्स और प्रत्येक सरणी [61] के लिए 12 बाइट्स का ओवरहेड है।^[60] यदि किसी वस्तु का आकार 8 बाइट्स का एक गुणक नहीं है, तो इसे 8 के अगले गुणक तक गोल किया जाता है। इसका मतलब है कि एक बाइट फ़ील्ड रखने वाली वस्तु 16 बाइट्स रखती है और उसे 4-बाइट संदर्भ की आवश्यकता होती है। C++ प्रत्येक वस्तु के लिए एक सूचक (आमतौर पर 4 या 8 बाइट्स) भी आवंटित करता है जो वर्ग प्रत्यक्ष या अप्रत्यक्ष रूप से वर्चूअल कार्यों की घोषणा करता है।^[61]
पता अंकगणित का अभाव मेमोरी-कुशल कंटेनर बनाता है, जैसे कि कसकर दूरी वाली संरचनाएं और एक्सओआर लिंक्ड सूचियां, वर्तमान में असंभव है (ओपनजेडीके वल्लाह परियोजना का उद्देश्य इन मुद्दों को कम करना है,यद्यपि इसका उद्देश्य सूचक अंकगणित को प्रस्तुत करना नहीं है; यह एक में नहीं किया जा सकता है) कचरा एकत्रित वातावरण)।
मॉलोक और नए के विपरीत, ढेर के आकार में वृद्धि के साथ कचरा संग्रह का औसत प्रदर्शन शून्य के करीब पहुंच जाता है (अधिक सटीक रूप से, एक सीपीयू चक्र)।^[62]
जावा वर्ग पुस्तकालय के कुछ हिस्सों को प्रोग्राम के निष्पादन से पहले भारण करना चाहिए (कम से कम एक प्रोग्राम के भीतर उपयोग की जाने वाली कक्षाएं)।^[63] यह छोटे अनुप्रयोगों के लिए एक महत्वपूर्ण मेमोरी ओवरहेड की ओर ले जाता है।^{[citation needed]}
जावा बाइनरी और मूल पुनर्संकलन दोनों सामान्यतः मेमोरी में होंगे।
वर्चुअल मशीन पर्याप्त मेमोरी का उपयोग करती है।
जावा में, एक समग्र वस्तु (कक्षा ए जो बी और सी के उदाहरणों का उपयोग करती है) बी और सी के आवंटित उदाहरणों के संदर्भों का उपयोग करके बनाई गई है। C++ में इस प्रकार के संदर्भों की मेमोरी और प्रदर्शन लागत से बचा जा सकता है जब बी और सी का उदाहरण /या C, A के भीतर मौजूद है।

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

त्रिकोणमितीय फलन

त्रिकोणमितीय फलनों का प्रदर्शन C की तुलना में खराब है, क्योंकि जावा में गणितीय संचालन के परिणामों के लिए सख्त विनिर्देश हैं, जो अंतर्निहित हार्डवेयर कार्यान्वयन के अनुरूप नहीं हो सकते हैं।^[64] x87 फ़्लोटिंग पॉइंट सबसेट पर, 1.4 से जावा सॉफ़्टवेयर में पाप और कॉस के लिए तर्क में कमी करता है,^[65] जिससे सीमा के बाहर मूल्यों के लिए एक बड़ा प्रदर्शन प्रभावित होता है।^[66]^{[clarification needed]}

जावा मूल इंटरफ़ेस

जावा मूल इंटरफ़ेस एक उच्च ओवरहेड का आह्वान करता है, जिससे जेवीएम और मूल कोड पर चलने वाले कोड के बीच की सीमा को पार करना महंगा हो जाता है।^[67]^[68] जावा नेटिव एक्सेस (जेएनए) जावा प्रोग्राम को केवल जावा कोड के माध्यम से मूल साझा पुस्तकालय (विंडोज़ पर डायनेमिक-लिंक पुस्तकालय (डीएलएल)) तक आसान पहुंच प्रदान करता है, जिसमें कोई जेएनआई या मूल कोड नहीं है। यह कार्यक्षमता विंडोज़ प्लेटफ़ॉर्म/इनवोक और पायथन के cप्रकार से तुलनीय है। कोड जनरेशन के बिना कार्यावधि पर एक्सेस डायनेमिक है। लेकिन इसकी एक कीमत होती है, और जेएनएसामान्यतः जेएनआई की तुलना में धीमी होती है।^[69]

यूजर इंटरफेस

स्विंग (जावा) को मूल विजेट टूलकिट की तुलना में धीमा माना गया है, क्योंकि यह विजेट के प्रतिपादन को स्पष्ट जावा 2डी एपीआई को दर्शाता है।यद्यपि, स्विंग बनाम मानक विजेट टूलकिट के प्रदर्शन की तुलना करने वाले बेंचमार्क, जो ऑपरेटिंग प्रणालियों के मूल जीयूआई पुस्तकालयों को प्रतिपादन का प्रतिनिधित्व करते हैं, कोई स्पष्ट विजेता नहीं दिखाता हैं, और परिणाम संदर्भ और वातावरण पर काफी हद तक निर्भर करते हैं।^[70] इसके अतिरिक्त, स्विंग को बदलने के उद्देश्य से नया जावा एफएक्स ढांचा, स्विंग के एकाधिक अंतर्निहित मुद्दों को संबोधित करता है। स्विंग को मूल विजेट टूलकिट की तुलना में धीमा माना गया है, क्योंकि यह स्पष्ट जावा 2D API पर विजेट्स का रेंडरिंग डेलिगेट्स करता है. हालांकि, बेंचमार्क स्विंग के प्रदर्शन बनाम मानक विजेट टूलकिट की तुलना करते हैं, जो ऑपरेटिंग सिस्टम के मूल GUI लाइब्रेरीज़ में रेंडरिंग प्रतिनिधियों को प्रस्तुत करता है, कोई स्पष्ट विजेता नहीं दिखाता है, और परिणाम संदर्भ और वातावरण पर काफी निर्भर करते हैं।[72] Addiaticialarate, नया जावाfx फ़्रेमवर्क, स्विंग को बदलने के इरादे से, स्विंग की कई निहित समस्याओं पर ध्यान देता है।

उच्च प्रदर्शन कंप्यूटिंग के लिए प्रयोग

कुछ लोगों का मानना है कि उच्च प्रदर्शन कंप्यूटिंग (एचपीसी) के लिए जावा प्रदर्शन गणना-गहन बेंचमार्क पर फोरट्रान के समान है, लेकिन ग्रिड कंप्यूटिंग नेटवर्क पर गहन संचार करने के लिए जेवीएम में अभी भी मापनीयता के मुद्दे हैं।^[71]

यद्यपि, जावा में लिखे गए उच्च प्रदर्शन वाले कंप्यूटिंग अनुप्रयोगों ने बेंचमार्क प्रतियोगिताओं में जीत प्राप्त की है। 2008,^[72] और 2009 में,^[73]^[74] एक अपाचे हडूप (जावा में लिखा गया एक ओपन-सोर्स हाई परफॉर्मेंस कंप्यूटिंग प्रोजेक्ट) आधारित क्लस्टर एक टेराबाइट और पेटाबाइट पूर्णांकों को सबसे तेजी से वर्गीकृत करने में सक्षम था। यद्यपि, प्रतिस्पर्धी प्रणालियों का हार्डवेयर सेटअप निश्चित नहीं किया गया था।^[75]^[76]

प्रोग्रामिंग प्रतियोगिता में

जावा में प्रोग्राम अन्य संकलित भाषाओं की तुलना में धीमी गति से प्रारम्भ होते हैं।^[77]^[78] इस प्रकार, कुछ ऑनलाइन जज प्रणालियों, विशेष रूप से चीनी विश्वविद्यालयों द्वारा आयोजन किए गए, जावा प्रोग्रामों के लिए लंबी समय सीमा का उपयोग करते हुए प्रतियोगी के निष्पक्ष होने के लिए करते हैं।^[79]^[80]^[81]^[82]^[83]

यह भी देखें

सामान्य भाषा कार्यावधि
प्रदर्शन विश्लेषण
जावा प्रोसेसर, एक अंतःस्थापित प्रोसेसर जो जावा बाइटकोड मूल रूप से संचालित कर रहा है (जैसे जेस्टिक)
जावा और C++ की तुलना
जावा संगामी मानचित्र

संदर्भ

↑ "Java versus C++ benchmarks".
↑ ^2.0 ^2.1 "Symantec's Just-In-Time Java Compiler To Be Integrated Into Sun JDK 1.1".
↑ "Short Take: Apple licenses Symantec's just-in-time compiler". cnet.com. May 12, 1998. Retrieved November 15, 2015.
↑ "Java gets four times faster with new Symantec just-in-time compiler".
↑ "Performance Comparison of Java/.NET Runtimes (Oct 2004)".
↑ Kawaguchi, Kohsuke (March 30, 2008). "Deep dive into assembly code from Java". Archived from the original on April 2, 2008. Retrieved April 2, 2008.
↑ "Fast, Effective Code Generation in a Just-In-Time Java Compiler" (PDF). Intel Corporation. Retrieved June 22, 2007.
↑ This article shows that the performance gain between interpreted mode and Hotspot amounts to more than a factor of 10.
↑ Numeric performance in C, C# and Java
↑ Algorithmic Performance Comparison Between C, C++, Java and C# Programming Languages Archived March 31, 2010, at the Wayback Machine
↑ "The Java HotSpot Virtual Machine, v1.4.1". Sun Microsystems. Retrieved April 20, 2008.
↑ Nutter, Charles (January 28, 2008). "Lang.NET 2008: Day 1 Thoughts". Retrieved January 18, 2011. Deoptimization is very exciting when dealing with performance concerns, since it means you can make much more aggressive optimizations...knowing you'll be able to fall back on a tried and true safe path later on
↑ IBM DeveloperWorks Library
↑ For example, the duration of pauses is less noticeable now. See for example this clone of Quake II written in Java: Jake2.
↑ "New Java SE 6 Feature: Type Checking Verifier". Java.net. Retrieved January 18, 2011.^{[permanent dead link]}
↑ Brian Goetz (October 18, 2005). "Java theory and practice: Synchronization optimizations in Mustang". IBM. Retrieved January 26, 2013.
↑ "Java HotSpot Virtual Machine Performance Enhancements". Oracle Corporation. Retrieved January 14, 2014. Escape analysis is a technique by which the Java Hotspot Server Compiler can analyze the scope of a new object's uses and decide whether to allocate it on the Java heap. Escape analysis is supported and enabled by default in Java SE 6u23 and later.
↑ Bug report: new register allocator, fixed in Mustang (JDK 6) b59
↑ Mustang's HotSpot Client gets 58% faster! Archived March 5, 2012, at the Wayback Machine in Osvaldo Pinali Doederlein's Blog at java.net
↑ Class Data Sharing at java.sun.com
↑ Class Data Sharing in JDK 1.5.0 in Java Buzz Forum at artima developer
↑ Mckay, Niali. "Java gets four times faster with new Symantec just-in-time compiler".
↑ Sun overview of performance improvements between 1.4 and 5.0 versions.
↑ STR-Crazier: Performance Improvements in Mustang Archived January 5, 2007, at the Wayback Machine in Chris Campbell's Blog at java.net
↑ See here for a benchmark showing a performance boost of about 60% from Java 5.0 to 6 for the application JFreeChart
↑ Java SE 6 Performance White Paper at http://java.sun.com
↑ ^27.0 ^27.1 Haase, Chet (May 2007). "Consumer JRE: Leaner, Meaner Java Technology". Sun Microsystems. Retrieved July 27, 2007. At the OS level, all of these megabytes have to be read from disk, which is a very slow operation. Actually, it's the seek time of the disk that's the killer; reading large files sequentially is relatively fast, but seeking the bits that we actually need is not. So even though we only need a small fraction of the data in these large files for any particular application, the fact that we're seeking all over within the files means that there is plenty of disk activity.
↑ Haase, Chet (May 2007). "Consumer JRE: Leaner, Meaner Java Technology". Sun Microsystems. Retrieved July 27, 2007.
↑ Haase, Chet (May 2007). "Consumer JRE: Leaner, Meaner Java Technology". Sun Microsystems. Retrieved July 27, 2007.
↑ Campbell, Chris (April 7, 2007). "Faster Java 2D Via Shaders". Archived from the original on June 5, 2011. Retrieved January 18, 2011.
↑ Haase, Chet (May 2007). "Consumer JRE: Leaner, Meaner Java Technology". Sun Microsystems. Retrieved July 27, 2007.
↑ "JSR 292: Supporting Dynamically Typed Languages on the Java Platform". jcp.org. Retrieved May 28, 2008.
↑ Goetz, Brian (March 4, 2008). "Java theory and practice: Stick a fork in it, Part 2". IBM. Retrieved March 9, 2008.
↑ Lorimer, R.J. (March 21, 2008). "Parallelism with Fork/Join in Java 7". infoq.com. Retrieved May 28, 2008.
↑ "New Compiler Optimizations in the Java HotSpot Virtual Machine" (PDF). Sun Microsystems. May 2006. Retrieved May 30, 2008.
↑ Humble, Charles (May 13, 2008). "JavaOne: Garbage First". infoq.com. Retrieved September 7, 2008.
↑ Coward, Danny (November 12, 2008). "Java VM: Trying a new Garbage Collector for JDK 7". Archived from the original on December 8, 2011. Retrieved November 15, 2008.
↑ "Computer Language Benchmarks Game". benchmarksgame.alioth.debian.org. Archived from the original on January 25, 2015. Retrieved June 2, 2011.
↑ "Computer Language Benchmarks Game". benchmarksgame.alioth.debian.org. Archived from the original on January 13, 2015. Retrieved June 2, 2011.
↑ "Computer Language Benchmarks Game". benchmarksgame.alioth.debian.org. Archived from the original on January 10, 2015. Retrieved June 2, 2011.
↑ "Computer Language Benchmarks Game". benchmarksgame.alioth.debian.org. Archived from the original on January 2, 2015. Retrieved June 2, 2011.
↑ :260/250 frame/s versus 245 frame/s (see benchmark)
↑ Hundt, Robert. "Loop Recognition in C++/Java/Go/Scala" (PDF). Scala Days 2011. Stanford, California. Retrieved March 23, 2014.
↑ L. Gherardi; D. Brugali; D. Comotti (2012). "A Java vs. C++ performance evaluation: a 3D modeling benchmark" (PDF). University of Bergamo. Retrieved March 23, 2014. Using the Server compiler, which is best tuned for long-running applications, have instead demonstrated that Java is from 1.09 to 1.91 times slower(...)In conclusion, the results obtained with the server compiler and these important features suggest that Java can be considered a valid alternative to C++
↑ "The Java HotSpot Performance Engine: Method Inlining Example". Oracle Corporation. Retrieved June 11, 2011.
↑ Nutter, Charles (May 3, 2008). "The Power of the JVM". Retrieved June 11, 2011. What happens if you've already inlined A's method when B comes along? Here again the JVM shines. Because the JVM is essentially a dynamic language runtime under the covers, it remains ever-vigilant, watching for exactly these sorts of events to happen. And here's the really cool part: when situations change, the JVM can deoptimize. This is a crucial detail. Many other runtimes can only do their optimization once. C compilers must do it all ahead of time, during the build. Some allow you to profile your application and feed that into subsequent builds, but once you've released a piece of code it's essentially as optimized as it will ever get. Other VM-like systems like the CLR do have a JIT phase, but it happens early in execution (maybe before the system even starts executing) and doesn't ever happen again. The JVM's ability to deoptimize and return to interpretation gives it room to be optimistic...room to make ambitious guesses and gracefully fall back to a safe state, to try again later.
↑ "Microbenchmarking C++, C#, and Java: 32-bit integer arithmetic". Dr. Dobb's Journal. July 1, 2005. Retrieved January 18, 2011.
↑ "Microbenchmarking C++, C#, and Java: 64-bit double arithmetic". Dr. Dobb's Journal. July 1, 2005. Retrieved January 18, 2011.
↑ "Microbenchmarking C++, C#, and Java: File I/O". Dr. Dobb's Journal. July 1, 2005. Retrieved January 18, 2011.
↑ "Microbenchmarking C++, C#, and Java: Exception". Dr. Dobb's Journal. July 1, 2005. Retrieved January 18, 2011.
↑ "Microbenchmarking C++, C#, and Java: Array". Dr. Dobb's Journal. July 1, 2005. Retrieved January 18, 2011.
↑ "Microbenchmarking C++, C#, and Java: Trigonometric functions". Dr. Dobb's Journal. July 1, 2005. Retrieved January 18, 2011.
↑ Yi Zhao, Jin Shi, Kai Zheng, Haichuan Wang, Haibo Lin and Ling Shao, Allocation wall: a limiting factor of Java applications on emerging multi-core platforms, Proceedings of the 24th ACM SIGPLAN conference on Object oriented programming systems languages and applications, 2009.
↑ C4: The Continuously Concurrent Compacting Collector
↑ Azul bullies Java with 768 core machine
↑ "Benchmark start-up and system performance for .Net, Mono, Java, C++ and their respective UI". September 2, 2010.
↑ "How fast is the new verifier?". 7 February 2006. Archived from the original on 16 May 2006. Retrieved 9 May 2007.
↑ Nailgun
↑ The Nailgun Background page demonstrates "best case scenario" speedup of 33 times (for scripted "Hello, World!" programs i.e., short-run programs).
↑ "How to calculate the memory usage of Java objects".
↑ "InformIT: C++ Reference Guide > the Object Model". Archived from the original on 21 February 2008. Retrieved 22 June 2009.
↑ https://www.youtube.com/watch?v=M91w0SBZ-wc : Understanding Java Garbage Collection - a talk by Gil Tene at JavaOne
↑ ".: ToMMTi-Systems :: Hinter den Kulissen moderner 3D-Hardware".
↑ "Math (Java Platform SE 6)". Sun Microsystems. Retrieved June 8, 2008.
↑ Gosling, James (July 27, 2005). "Transcendental Meditation". Archived from the original on August 12, 2011. Retrieved June 8, 2008.
↑ W. Cowell-Shah, Christopher (January 8, 2004). "Nine Language Performance Round-up: Benchmarking Math & File I/O". Archived from the original on October 11, 2018. Retrieved June 8, 2008.
↑ Wilson, Steve; Jeff Kesselman (2001). "JavaTM Platform Performance: Using Native Code". Sun Microsystems. Retrieved February 15, 2008.
↑ Kurzyniec, Dawid; Vaidy Sunderam. "Efficient Cooperation between Java and Native Codes - JNI Performance Benchmark" (PDF). Archived from the original (PDF) on 14 February 2005. Retrieved 15 February 2008.
↑ "How does JNA performance compare to custom JNI?". Sun Microsystems. Retrieved December 26, 2009.^{[permanent dead link]}
↑ Igor, Križnar (10 May 2005). "SWT Vs. Swing Performance Comparison" (PDF). cosylab.com. Archived from the original (PDF) on 4 July 2008. Retrieved 24 May 2008. It is hard to give a rule-of-thumb where SWT would outperform Swing, or vice versa. In some environments (e.g., Windows), SWT is a winner. In others (Linux, VMware hosting Windows), Swing and its redraw optimization outperform SWT significantly. Differences in performance are significant: factors of 2 and more are common, in either direction
↑ Brian Amedro; Vladimir Bodnartchouk; Denis Caromel; Christian Delbe; Fabrice Huet; Guillermo L. Taboada (August 2008). "Current State of Java for HPC". INRIA. Retrieved September 9, 2008. We first perform some micro benchmarks for various JVMs, showing the overall good performance for basic arithmetic operations(...). Comparing this implementation with a Fortran/MPI one, we show that they have similar performance on computation intensive benchmarks, but still have scalability issues when performing intensive communications.
↑ Owen O'Malley - Yahoo! Grid Computing Team (July 2008). "Apache Hadoop Wins Terabyte Sort Benchmark". Archived from the original on 15 October 2009. Retrieved 21 December 2008. This is the first time that either a Java or an open source program has won.
↑ "Hadoop Sorts a Petabyte in 16.25 Hours and a Terabyte in 62 Seconds". CNET.com. May 11, 2009. Archived from the original on May 16, 2009. Retrieved September 8, 2010. The hardware and operating system details are:(...)Sun Java JDK (1.6.0_05-b13 and 1.6.0_13-b03) (32 and 64 bit)
↑ "Hadoop breaks data-sorting world records". CNET.com. May 15, 2009. Retrieved September 8, 2010.
↑ Chris Nyberg; Mehul Shah. "Sort Benchmark Home Page". Retrieved November 30, 2010.
↑ Czajkowski, Grzegorz (November 21, 2008). "Sorting 1PB with MapReduce". Retrieved December 1, 2010.
↑ "TCO10". Archived from the original on 18 October 2010. Retrieved 21 June 2010.
↑ "How to write Java solutions @ Timus Online Judge".
↑ "FAQ".
↑ "FAQ | TJU ACM-ICPC Online Judge". Archived from the original on June 29, 2010. Retrieved May 25, 2010.
↑ "FAQ | CodeChef".
↑ "HomePage of Xidian Univ. Online Judge". Archived from the original on 19 February 2012. Retrieved 13 November 2011.
↑ "FAQ".

बाहरी संबंध

[45] Contention of this nature can be alleviated in C++ programs at the source code level by employing advanced methods such as custom allocators, exploiting precisely the kind of low-level coding complexity that Java was designed to conceal and encapsulate; however, this approach is rarely practical if not adopted (or at least anticipated) while the program remains under primary development.

[1] "Java versus C++ benchmarks".

[symantec.com-2] 2.0 ^2.1 "Symantec's Just-In-Time Java Compiler To Be Integrated Into Sun JDK 1.1".

[cnet1998-3] "Short Take: Apple licenses Symantec's just-in-time compiler". cnet.com. May 12, 1998. Retrieved November 15, 2015.

[4] "Java gets four times faster with new Symantec just-in-time compiler".

[5] "Performance Comparison of Java/.NET Runtimes (Oct 2004)".

[6] Kawaguchi, Kohsuke (March 30, 2008). "Deep dive into assembly code from Java". Archived from the original on April 2, 2008. Retrieved April 2, 2008.

[7] "Fast, Effective Code Generation in a Just-In-Time Java Compiler" (PDF). Intel Corporation. Retrieved June 22, 2007.

[8] This article shows that the performance gain between interpreted mode and Hotspot amounts to more than a factor of 10.

[9] Numeric performance in C, C# and Java

[10] Algorithmic Performance Comparison Between C, C++, Java and C# Programming Languages Archived March 31, 2010, at the Wayback Machine

[11] "The Java HotSpot Virtual Machine, v1.4.1". Sun Microsystems. Retrieved April 20, 2008.

[12] Nutter, Charles (January 28, 2008). "Lang.NET 2008: Day 1 Thoughts". Retrieved January 18, 2011. Deoptimization is very exciting when dealing with performance concerns, since it means you can make much more aggressive optimizations...knowing you'll be able to fall back on a tried and true safe path later on

[13] IBM DeveloperWorks Library

[14] For example, the duration of pauses is less noticeable now. See for example this clone of Quake II written in Java: Jake2.

[15] "New Java SE 6 Feature: Type Checking Verifier". Java.net. Retrieved January 18, 2011.^{[permanent dead link]}

[16] Brian Goetz (October 18, 2005). "Java theory and practice: Synchronization optimizations in Mustang". IBM. Retrieved January 26, 2013.

[17] "Java HotSpot Virtual Machine Performance Enhancements". Oracle Corporation. Retrieved January 14, 2014. Escape analysis is a technique by which the Java Hotspot Server Compiler can analyze the scope of a new object's uses and decide whether to allocate it on the Java heap. Escape analysis is supported and enabled by default in Java SE 6u23 and later.

[18] Bug report: new register allocator, fixed in Mustang (JDK 6) b59

[19] Mustang's HotSpot Client gets 58% faster! Archived March 5, 2012, at the Wayback Machine in Osvaldo Pinali Doederlein's Blog at java.net

[20] Class Data Sharing at java.sun.com

[21] Class Data Sharing in JDK 1.5.0 in Java Buzz Forum at artima developer

[symantec_compiler-22] Mckay, Niali. "Java gets four times faster with new Symantec just-in-time compiler".

[23] Sun overview of performance improvements between 1.4 and 5.0 versions.

[24] STR-Crazier: Performance Improvements in Mustang Archived January 5, 2007, at the Wayback Machine in Chris Campbell's Blog at java.net

[25] See here for a benchmark showing a performance boost of about 60% from Java 5.0 to 6 for the application JFreeChart

[26] Java SE 6 Performance White Paper at http://java.sun.com

[jrecache-27] 27.0 ^27.1 Haase, Chet (May 2007). "Consumer JRE: Leaner, Meaner Java Technology". Sun Microsystems. Retrieved July 27, 2007. At the OS level, all of these megabytes have to be read from disk, which is a very slow operation. Actually, it's the seek time of the disk that's the killer; reading large files sequentially is relatively fast, but seeking the bits that we actually need is not. So even though we only need a small fraction of the data in these large files for any particular application, the fact that we're seeking all over within the files means that there is plenty of disk activity.

[28] Haase, Chet (May 2007). "Consumer JRE: Leaner, Meaner Java Technology". Sun Microsystems. Retrieved July 27, 2007.

[29] Haase, Chet (May 2007). "Consumer JRE: Leaner, Meaner Java Technology". Sun Microsystems. Retrieved July 27, 2007.

[30] Campbell, Chris (April 7, 2007). "Faster Java 2D Via Shaders". Archived from the original on June 5, 2011. Retrieved January 18, 2011.

[31] Haase, Chet (May 2007). "Consumer JRE: Leaner, Meaner Java Technology". Sun Microsystems. Retrieved July 27, 2007.

[32] "JSR 292: Supporting Dynamically Typed Languages on the Java Platform". jcp.org. Retrieved May 28, 2008.

[33] Goetz, Brian (March 4, 2008). "Java theory and practice: Stick a fork in it, Part 2". IBM. Retrieved March 9, 2008.

[34] Lorimer, R.J. (March 21, 2008). "Parallelism with Fork/Join in Java 7". infoq.com. Retrieved May 28, 2008.

[35] "New Compiler Optimizations in the Java HotSpot Virtual Machine" (PDF). Sun Microsystems. May 2006. Retrieved May 30, 2008.

[36] Humble, Charles (May 13, 2008). "JavaOne: Garbage First". infoq.com. Retrieved September 7, 2008.

[37] Coward, Danny (November 12, 2008). "Java VM: Trying a new Garbage Collector for JDK 7". Archived from the original on December 8, 2011. Retrieved November 15, 2008.

[38] "Computer Language Benchmarks Game". benchmarksgame.alioth.debian.org. Archived from the original on January 25, 2015. Retrieved June 2, 2011.

[39] "Computer Language Benchmarks Game". benchmarksgame.alioth.debian.org. Archived from the original on January 13, 2015. Retrieved June 2, 2011.

[40] "Computer Language Benchmarks Game". benchmarksgame.alioth.debian.org. Archived from the original on January 10, 2015. Retrieved June 2, 2011.

[41] "Computer Language Benchmarks Game". benchmarksgame.alioth.debian.org. Archived from the original on January 2, 2015. Retrieved June 2, 2011.

[42] :260/250 frame/s versus 245 frame/s (see benchmark)

[43] Hundt, Robert. "Loop Recognition in C++/Java/Go/Scala" (PDF). Scala Days 2011. Stanford, California. Retrieved March 23, 2014.

[44] L. Gherardi; D. Brugali; D. Comotti (2012). "A Java vs. C++ performance evaluation: a 3D modeling benchmark" (PDF). University of Bergamo. Retrieved March 23, 2014. Using the Server compiler, which is best tuned for long-running applications, have instead demonstrated that Java is from 1.09 to 1.91 times slower(...)In conclusion, the results obtained with the server compiler and these important features suggest that Java can be considered a valid alternative to C++

[46] "The Java HotSpot Performance Engine: Method Inlining Example". Oracle Corporation. Retrieved June 11, 2011.

[47] Nutter, Charles (May 3, 2008). "The Power of the JVM". Retrieved June 11, 2011. What happens if you've already inlined A's method when B comes along? Here again the JVM shines. Because the JVM is essentially a dynamic language runtime under the covers, it remains ever-vigilant, watching for exactly these sorts of events to happen. And here's the really cool part: when situations change, the JVM can deoptimize. This is a crucial detail. Many other runtimes can only do their optimization once. C compilers must do it all ahead of time, during the build. Some allow you to profile your application and feed that into subsequent builds, but once you've released a piece of code it's essentially as optimized as it will ever get. Other VM-like systems like the CLR do have a JIT phase, but it happens early in execution (maybe before the system even starts executing) and doesn't ever happen again. The JVM's ability to deoptimize and return to interpretation gives it room to be optimistic...room to make ambitious guesses and gracefully fall back to a safe state, to try again later.

[48] "Microbenchmarking C++, C#, and Java: 32-bit integer arithmetic". Dr. Dobb's Journal. July 1, 2005. Retrieved January 18, 2011.

[49] "Microbenchmarking C++, C#, and Java: 64-bit double arithmetic". Dr. Dobb's Journal. July 1, 2005. Retrieved January 18, 2011.

[50] "Microbenchmarking C++, C#, and Java: File I/O". Dr. Dobb's Journal. July 1, 2005. Retrieved January 18, 2011.

[51] "Microbenchmarking C++, C#, and Java: Exception". Dr. Dobb's Journal. July 1, 2005. Retrieved January 18, 2011.

[52] "Microbenchmarking C++, C#, and Java: Array". Dr. Dobb's Journal. July 1, 2005. Retrieved January 18, 2011.

[53] "Microbenchmarking C++, C#, and Java: Trigonometric functions". Dr. Dobb's Journal. July 1, 2005. Retrieved January 18, 2011.

[54] Yi Zhao, Jin Shi, Kai Zheng, Haichuan Wang, Haibo Lin and Ling Shao, Allocation wall: a limiting factor of Java applications on emerging multi-core platforms, Proceedings of the 24th ACM SIGPLAN conference on Object oriented programming systems languages and applications, 2009.

[55] C4: The Continuously Concurrent Compacting Collector

[56] Azul bullies Java with 768 core machine

[57] "Benchmark start-up and system performance for .Net, Mono, Java, C++ and their respective UI". September 2, 2010.

[58] "How fast is the new verifier?". 7 February 2006. Archived from the original on 16 May 2006. Retrieved 9 May 2007.

[59] Nailgun

[60] The Nailgun Background page demonstrates "best case scenario" speedup of 33 times (for scripted "Hello, World!" programs i.e., short-run programs).

[61] "How to calculate the memory usage of Java objects".

[62] "InformIT: C++ Reference Guide > the Object Model". Archived from the original on 21 February 2008. Retrieved 22 June 2009.

[63] ttps://www.youtube.com/watch?v=M91w0SBZ-wc : Understanding Java Garbage Collection - a talk by Gil Tene at JavaOne

[64] ".: ToMMTi-Systems :: Hinter den Kulissen moderner 3D-Hardware".

[65] "Math (Java Platform SE 6)". Sun Microsystems. Retrieved June 8, 2008.

[66] Gosling, James (July 27, 2005). "Transcendental Meditation". Archived from the original on August 12, 2011. Retrieved June 8, 2008.

[67] W. Cowell-Shah, Christopher (January 8, 2004). "Nine Language Performance Round-up: Benchmarking Math & File I/O". Archived from the original on October 11, 2018. Retrieved June 8, 2008.

[68] Wilson, Steve; Jeff Kesselman (2001). "JavaTM Platform Performance: Using Native Code". Sun Microsystems. Retrieved February 15, 2008.

[69] Kurzyniec, Dawid; Vaidy Sunderam. "Efficient Cooperation between Java and Native Codes - JNI Performance Benchmark" (PDF). Archived from the original (PDF) on 14 February 2005. Retrieved 15 February 2008.

[70] "How does JNA performance compare to custom JNI?". Sun Microsystems. Retrieved December 26, 2009.^{[permanent dead link]}

[71] Igor, Križnar (10 May 2005). "SWT Vs. Swing Performance Comparison" (PDF). cosylab.com. Archived from the original (PDF) on 4 July 2008. Retrieved 24 May 2008. It is hard to give a rule-of-thumb where SWT would outperform Swing, or vice versa. In some environments (e.g., Windows), SWT is a winner. In others (Linux, VMware hosting Windows), Swing and its redraw optimization outperform SWT significantly. Differences in performance are significant: factors of 2 and more are common, in either direction

[72] Brian Amedro; Vladimir Bodnartchouk; Denis Caromel; Christian Delbe; Fabrice Huet; Guillermo L. Taboada (August 2008). "Current State of Java for HPC". INRIA. Retrieved September 9, 2008. We first perform some micro benchmarks for various JVMs, showing the overall good performance for basic arithmetic operations(...). Comparing this implementation with a Fortran/MPI one, we show that they have similar performance on computation intensive benchmarks, but still have scalability issues when performing intensive communications.

[73] Owen O'Malley - Yahoo! Grid Computing Team (July 2008). "Apache Hadoop Wins Terabyte Sort Benchmark". Archived from the original on 15 October 2009. Retrieved 21 December 2008. This is the first time that either a Java or an open source program has won.

[74] "Hadoop Sorts a Petabyte in 16.25 Hours and a Terabyte in 62 Seconds". CNET.com. May 11, 2009. Archived from the original on May 16, 2009. Retrieved September 8, 2010. The hardware and operating system details are:(...)Sun Java JDK (1.6.0_05-b13 and 1.6.0_13-b03) (32 and 64 bit)

[75] "Hadoop breaks data-sorting world records". CNET.com. May 15, 2009. Retrieved September 8, 2010.

[76] Chris Nyberg; Mehul Shah. "Sort Benchmark Home Page". Retrieved November 30, 2010.

[googlemapreduce-77] Czajkowski, Grzegorz (November 21, 2008). "Sorting 1PB with MapReduce". Retrieved December 1, 2010.

[78] "TCO10". Archived from the original on 18 October 2010. Retrieved 21 June 2010.

[79] "How to write Java solutions @ Timus Online Judge".

[80] "FAQ".

[81] "FAQ | TJU ACM-ICPC Online Judge". Archived from the original on June 29, 2010. Retrieved May 25, 2010.

[82] "FAQ | CodeChef".

[83] "HomePage of Xidian Univ. Online Judge". Archived from the original on 19 February 2012. Retrieved 13 November 2011.

[84] "FAQ".

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]

[23]

[24]

[25]

[26]

[27]

[28]

[29]

[30]

[31]

[32]

[33]

[34]

[35]

[36]

[37]

[38]

[39]

[40]

[41]

[42]

[43]

[44]

[note 1]

[45]

[46]

[47]

[48]

[49]

[50]

[51]

[52]

[53]

[54]

[55]

[56]

[57]

[58]

[59]

[60]

[61]

[62]

[63]

[64]

[65]

[66]

[67]

[68]

[69]

[70]

[71]

[72]

[73]

[74]

[75]

[76]

[77]

[78]

[79]

[80]

[81]

[82]

[83]

Anonymous

Search

जावा-परफॉरमेंस: Difference between revisions

Namespaces

More

Page actions

Latest revision as of 13:58, 7 July 2023

Contents

वर्चूअल मशीन अनुकूलन पद्धतियाँ

जस्ट-इन-टाइम संकलन

अनुकूली अनुकूलन

कचरा संग्रह

अन्य अनुकूलन विधियां

संकुचित उफ़

विभाजन बाइटकोड सत्यापन

एस्केप एनालिसिस और लॉक कोर्सनिंग

आवंटन सुधार दर्ज करें

वर्ग डेटा शेयरिंग

प्रदर्शन में सुधार का इतिहास

जावा एसई 6 अपडेट 10

जावा 7

अन्य भाषाओं की तुलना

प्रोग्राम की गति

बहु-कोर प्रदर्शन

स्टार्टअप समय

मेमोरी उपयोग

त्रिकोणमितीय फलन

जावा मूल इंटरफ़ेस

यूजर इंटरफेस

उच्च प्रदर्शन कंप्यूटिंग के लिए प्रयोग

प्रोग्रामिंग प्रतियोगिता में

यह भी देखें

संदर्भ

बाहरी संबंध

Navigation

Navigation

Wiki tools

Wiki tools

@@ Line 8: / Line 8: @@
 }}</ref><ref name=cnet1998/><ref>{{cite web
 | url=http://grnlight.net/index.php/programming-articles/116-java-gets-four-times-faster-with-new-symantec-just-in-time-compiler
-| title=Java gets four times faster with new Symantec just-in-time compiler}}</ref> बेहतर कोड विश्लेषण का समर्थन करने वाली भाषा सुविधाओं के परिचय के माध्यम से जावा प्रोग्रामों की निष्पादन गति में काफी सुधार हुआ। जेवीएम में विश्लेषण, जावा बाइटकोड के हार्डवेयर निष्पादन, जैसे कि एआरएम के [[Jazelle|जज़ेल]] द्वारा प्रस्तुत किया गया, अनुकूलन को भी(जैसे [[हॉटस्पॉट (वर्चुअल मशीन)|हॉटस्पॉट]] 2000 में [[सन माइक्रोसिस्टम्स|सन]] के जेवीएम के लिए अकरण बन गया) और महत्वपूर्ण प्रदर्शन सुधार प्रस्तुत करने के लिए खोज की गई थी।
+| title=Java gets four times faster with new Symantec just-in-time compiler}}</ref> बेहतर कोड विश्लेषण का समर्थन करने वाली भाषा सुविधाओं के परिचय के माध्यम से जावा प्रोग्रामों की निष्पादन गति में काफी सुधार हुआ। जेवीएम में विश्लेषण, जावा बाइटकोड के हार्डवेयर निष्पादन, जैसे कि एआरएम के [[Jazelle|जज़ेल]] द्वारा प्रस्तुत किया गया, अनुकूलन को भी (जैसे [[हॉटस्पॉट (वर्चुअल मशीन)|हॉटस्पॉट]] 2000 में [[सन माइक्रोसिस्टम्स|सन]] के जेवीएम के लिए अकरण बन गया) और महत्वपूर्ण प्रदर्शन सुधार प्रस्तुत करने के लिए खोज की गई थी।
-[[जावा बाइटकोड]] संकलित जावा प्रोग्राम का प्रदर्शन इस बात पर निर्भर करता है कि उसके दिए गए कार्यों के समूह को जावा वर्चुअल मशीन (जेवीएम) द्वारा कितना प्रबंधित किया जाता है, और जेवीएम ऐसा करने में [[कंप्यूटर हार्डवेयर]] और [[ऑपरेटिंग सिस्टम]] (ओएस) की सुविधाओं का कितना अच्छा उपयोग करता है। इस प्रकार, किसी भी जावा प्रदर्शन परीक्षण या तुलना में हमेशा प्रयुक्त जेवीएम के संस्करण, वेन्डर, ओएस और हार्डवेयर संरचना की जानकारी करनी होती है। इसी तरह, समतुल्य मूल रूप से संकलित प्रोग्राम का प्रदर्शन उसके उत्पन्न मशीन कोड की गुणवत्ता पर निर्भर करेगा, इसलिए परीक्षण या तुलना में उपयोग किए गए संकलक के नाम, संस्करण और वेन्डर और उसके सक्रिय [[संकलक अनुकूलन]] निर्देशों की भी जानकारी करनी होगी।
+[[जावा बाइटकोड]] संकलित जावा प्रोग्राम का प्रदर्शन इस बात पर निर्भर करता है कि उसके दिए गए कार्यों के समूह को जावा वर्चुअल मशीन (जेवीएम) द्वारा कितना प्रबंधित किया जाता है, और जेवीएम ऐसा करने में [[कंप्यूटर हार्डवेयर]] और [[ऑपरेटिंग सिस्टम|ऑपरेटिंग प्रणालियों]] (ओएस) की सुविधाओं का कितना अच्छा उपयोग करता है। इस प्रकार, किसी भी जावा प्रदर्शन परीक्षण या तुलना में हमेशा प्रयुक्त जेवीएम के संस्करण, वेन्डर, ओएस और हार्डवेयर संरचना की जानकारी करनी होती है। इसी तरह, समतुल्य मूल रूप से संकलित प्रोग्राम का प्रदर्शन उसके उत्पन्न मशीन कोड की गुणवत्ता पर निर्भर करेगा, इसलिए परीक्षण या तुलना में उपयोग किए गए संकलक के नाम, संस्करण और वेन्डर और उसके सक्रिय [[संकलक अनुकूलन]] निर्देशों की भी जानकारी करनी होगी।
 == वर्चूअल मशीन अनुकूलन पद्धतियाँ ==
@@ Line 57: / Line 57: @@
 ==== संकुचित उफ़ ====
--बिट संदर्भों के साथ संपीड़ित ऊप्स जावा 5.0+ को 32 जीबी तक के संग्रह को संबोधित करने की अनुमति देता है। जावा व्यक्तिगत बाइट्स तक पहुँच का समर्थन नहीं करता है, केवल विषय जो अकरण रूप से 8 बाइट संरेखित हैं। इस कारण से, संग्रह संदर्भ के सबसे कम 3 बिट्स हमेशा 0 होंगे। 32-बिट संदर्भों के 8 बाइट खंडोंों के संकल्प को कम करके, पता योग्य स्थान को 32 जीबी तक बढ़ाया जा सकता है। यह 64-बिट संदर्भों का उपयोग करने की तुलना में मेमोरी उपयोग को महत्वपूर्ण रूप से कम करता है क्योंकि जावा C++ जैसी कुछ भाषाओं की तुलना में संदर्भों का अधिक उपयोग करता है। जावा 8 32-बिट संदर्भों के साथ 64 GB तक समर्थन करने के लिए 16-बाइट संरेखण जैसे बड़े संरेखण का समर्थन करता है।{{Citation needed|date=July 2019}}
+-बिट संदर्भों के साथ संपीड़ित ऊप्स जावा 5.0+ को 32 जीबी तक के संग्रह को संबोधित करने की अनुमति देता है। जावा व्यक्तिगत बाइट्स तक पहुँच का समर्थन नहीं करता है, केवल विषय जो अकरण रूप से 8 बाइट संरेखित हैं। इस कारण से, संग्रह संदर्भ के सबसे कम 3 बिट्स हमेशा 0 होंगे। 32-बिट संदर्भों के 8 बाइट खंडोंों के संकल्प को कम करके, पता योग्य स्थान को 32 जीबी तक बढ़ाया जा सकता है। यह 64-बिट संदर्भों का उपयोग करने की तुलना में मेमोरी उपयोग को महत्वपूर्ण रूप से कम करता है क्योंकि जावा C++ जैसी कुछ भाषाओं की तुलना में संदर्भों का अधिक उपयोग करता है। जावा 8 32-बिट संदर्भों के साथ 64 GB तक समर्थन करने के लिए 16-बाइट संरेखण जैसे बड़े संरेखण का समर्थन करता है।
-==== स्प्लिट बाइटकोड सत्यापन ====
+==== विभाजन बाइटकोड सत्यापन ====
 एक [[कक्षा (कंप्यूटर विज्ञान)|वर्ग (कंप्यूटर विज्ञान)]] को क्रियान्वित करने से पहले, सन जेवीएम अपने जावा बाइटकोड को सत्यापित करता है (बायटेकोड सत्यापनकर्ता देखें)। यह सत्यापन लज़ीली से किया जाता है: वर्गों के बायटेकोड केवल तभी लोड और सत्यापित होते हैं जब विशिष्ट वर्ग को लोड किया जाता है और उपयोग के लिए तैयार किया जाता है, न कि प्रोग्राम की प्रारम्भ में। यद्यपि, जावा वर्ग पुस्तकालय भी नियमित जावा वर्ग हैं, जब उनका उपयोग किया जाता है, तो उन्हें भी लोड किया जाना चाहिए, जिसका अर्थ है कि जावा प्रोग्राम का प्रारंभ समय अधिकांशतः C ++ प्रोग्राम की तुलना में अधिक लंबा होता है, उदाहरण के लिए।
@@ Line 70: / Line 70: @@
 * कार्यावधि - जब किसी वर्ग को भारण किया जाता है।
-व्यवहार में यह विधि ज्ञान को प्रग्रहण करके काम करती है कि जावा संकलक में वर्ग प्रवाह है की जानकारी का एक सारांश के साथ संकलित विधि बायटेकोड एनोटेट करता है। यह [[रनटाइम सत्यापन|कार्यावधि सत्यापन]] को पर्याप्त रूप से कम जटिल नहीं बनाता है, लेकिन कुछ शॉर्टकट की अनुमति देता है।{{Citation needed|date=February 2010}}
+व्यवहार में यह विधि ज्ञान को प्रग्रहण करके काम करती है कि जावा संकलक में वर्ग प्रवाह है की जानकारी का एक सारांश के साथ संकलित विधि बायटेकोड एनोटेट करता है। यह [[रनटाइम सत्यापन|कार्यावधि सत्यापन]] को पर्याप्त रूप से कम जटिल नहीं बनाता है, लेकिन कुछ शॉर्टकट की अनुमति देता है।
 ==== एस्केप एनालिसिस और लॉक कोर्सनिंग ====
 {{Further|लॉक (कंप्यूटर विज्ञान)|एस्केप एनालिसिस }}
-जावा भाषा स्तर पर मल्टीथ्रेडिंग का प्रबंधन करने में सक्षम है। मल्टीथ्रेडिंग एक विधि है जो प्रोग्राम को एकाधिक प्रक्रियाओं को समवर्ती रूप से करने की अनुमति देती है, इस प्रकार [[कंप्यूटर प्रणाली|कंप्यूटर सिस्टम]] पर एकाधिक प्रोसेसर या कोर के साथ तेजी से प्रोग्राम तैयार करती है। इसके अलावा, मल्टीथ्रेडेड एप्लिकेशन लंबे समय तक चलने वाले कार्यों को करते हुए भी इनपुट के प्रति उत्तरदायी रह सकता है।
+जावा भाषा स्तर पर मल्टीथ्रेडिंग का प्रबंधन करने में सक्षम है। मल्टीथ्रेडिंग एक विधि है जो प्रोग्राम को एकाधिक प्रक्रियाओं को समवर्ती रूप से करने की अनुमति देती है, इस प्रकार [[कंप्यूटर प्रणाली|कंप्यूटर प्रणालियों]] पर एकाधिक प्रोसेसर या कोर के साथ तेजी से प्रोग्राम तैयार करती है। इसके अलावा, मल्टीथ्रेडेड विनियोग लंबे समय तक चलने वाले कार्यों को करते हुए भी इनपुट के प्रति उत्तरदायी रह सकता है।
-यद्यपि, प्रोग्राम जो मल्टीथ्रेडिंग का उपयोग करते हैं, उन्हें थ्रेड्स के बीच साझा वस्तुओं की अतिरिक्त देखभाल करने की आवश्यकता होती है, जब वे किसी थ्रेड द्वारा उपयोग किए जाने पर साझा विधियों या [[ब्लॉक (प्रोग्रामिंग)|खंडों]] तक पहुँच को लॉक कर देते हैं। अंतर्निहित ऑपरेटिंग सिस्टम-स्तरीय परिचालन की प्रकृति के कारण खंडों या विषय को लॉक करना एक समय लेने वाला परिचालन है (संगामिति नियंत्रण और लॉक ग्रैन्युलैरिटी देखें)।
+यद्यपि, प्रोग्राम जो मल्टीथ्रेडिंग का उपयोग करते हैं, उन्हें थ्रेड्स के बीच साझा वस्तुओं की अतिरिक्त देखभाल करने की आवश्यकता होती है, जब वे किसी थ्रेड द्वारा उपयोग किए जाने पर साझा विधियों या [[ब्लॉक (प्रोग्रामिंग)|खंडों]] तक पहुँच को लॉक कर देते हैं। अंतर्निहित ऑपरेटिंग प्रणालियों-स्तरीय परिचालन की प्रकृति के कारण खंडों या विषय को लॉक करना एक समय लेने वाला परिचालन है (संगामिति नियंत्रण और लॉक ग्रैन्युलैरिटी देखें)।
 जैसा कि जावा पुस्तकालय को यह नहीं पता है कि एक से अधिक थ्रेड्स द्वारा कौन सी विधियों का उपयोग किया जाएगा, मानक पुस्तकालय हमेशा मल्टीथ्रेडेड वातावरण में आवश्यकता पड़ने पर खंडों को लॉक कर देती है।
-जावा 6 से पहले, वर्चुअल मशीन हमेशा प्रोग्राम द्वारा पूछे जाने पर विषय्स और खंडों को अवरोधित कर देती थी, भले ही किसी विषय को एक साथ दो अलग-अलग थ्रेड्स द्वारा संशोधित किए जाने का कोई जोखिम न हो। उदाहरण के लिए, इस स्थिति में, प्रत्येक ऐड ऑपरेशंस से पहले एक स्थानीय {{code|वेक्टर}}लॉक किया गया था ताकि यह सुनिश्चित किया जा सके कि इसे अन्य थ्रेड्स द्वारा संशोधित नहीं किया जाएगा (वेक्टर सिंक्रनाइज़ है), लेकिन क्योंकि यह विधि के लिए सख्ती से स्थानीय है, यह अनावश्यक है:                                                                                     जावा 6 से पहले, आभासी मशीन हमेशा प्रोग्राम द्वारा मांगे जाने पर वस्तुओं और खंडों को अवरोधित करती है, भले ही एक बार में दो भिन्न थ्रेड द्वारा किसी वस्तु को संशोधित किए जाने का कोई जोखिम न हो. उदाहरण के लिए, इस स्थिति में, एक स्थानीय वेक्टर प्रत्येक जोड़े कार्रवाई से पहले यह सुनिश्चित करने के लिए लॉक कर दिया गया था कि इसे अन्य थ्रेड द्वारा संशोधित नहीं किया जाएगा (वेक्टर सिंक्रनाइज़ किया गया है), क्योंकि यह विधि के लिए पूरी तरह से स्थानीय है इसलिए यह अनावश्यक है:
+जावा 6 से पहले, वर्चुअल मशीन हमेशा प्रोग्राम द्वारा पूछे जाने पर विषय्स और खंडों को अवरोधित कर देती थी, भले ही किसी विषय को एक साथ दो अलग-अलग थ्रेड्स द्वारा संशोधित किए जाने का कोई जोखिम न हो। उदाहरण के लिए, इस स्थिति में, प्रत्येक ऐड संचालन से पहले एक स्थानीय {{code|वेक्टर}}लॉक किया गया था ताकि यह सुनिश्चित किया जा सके कि इसे अन्य थ्रेड्स द्वारा संशोधित नहीं किया जाएगा (वेक्टर सिंक्रनाइज़ है), लेकिन क्योंकि यह विधि के लिए सख्ती से स्थानीय है, यह अनावश्यक है:                                                                                     जावा 6 से पहले, आभासी मशीन हमेशा प्रोग्राम द्वारा मांगे जाने पर वस्तुओं और खंडों को अवरोधित करती है, भले ही एक बार में दो भिन्न थ्रेड द्वारा किसी वस्तु को संशोधित किए जाने का कोई जोखिम न हो. उदाहरण के लिए, इस स्थिति में, एक स्थानीय वेक्टर प्रत्येक जोड़े कार्रवाई से पहले यह सुनिश्चित करने के लिए लॉक कर दिया गया था कि इसे अन्य थ्रेड द्वारा संशोधित नहीं किया जाएगा (वेक्टर सिंक्रनाइज़ किया गया है), क्योंकि यह विधि के लिए पूरी तरह से स्थानीय है इसलिए यह अनावश्यक है:
+<syntaxhighlight lang="java">
-<code>'''public''' String getNames() {</code>
+public String getNames() {
+     final Vector<String> v = new Vector<>();
-<code>Vector<String> v = '''new''' Vector<>();</code>
+     v.add("Me");
+     v.add("You");
-<code>v.add("Me");</code>
+     v.add("Her");
+     return v.toString();
-<code>v.add("You");</code>
+}
+</syntaxhighlight>
-<code>v.add("Her");</code>
-<code>'''return''' v.toString();</code>
-<code>}</code>
 जावा 6 कोड खंडों और विषय से प्रारम्भ होकर,केवल आवश्यकता होने पर ही लॉक हो जाते हैं,,<ref>{{cite web
@@ Line 108: / Line 103: @@
 |publisher=[[Oracle Corporation]]
 |quote=''Escape analysis is a technique by which the Java Hotspot Server Compiler can analyze the scope of a new object's uses and decide whether to allocate it on the Java heap. Escape analysis is supported and enabled by default in Java SE 6u23 and later.''
 |access-date=January 14, 2014}}</ref>
 ==== आवंटन सुधार दर्ज करें ====
 जावा 6 से पहले, रजिस्टरों का आवंटन क्लाइंट वर्चुअल मशीन में बहुत ही साधारण था (वे खंडों में नहीं रहते थे), जो कि [[सीपीयू डिजाइन|सीपीयू प्रारुपों]] में एक समस्या थी, जिसमें कम [[प्रोसेसर रजिस्टर]] उपलब्ध थे, जैसा कि [[86|x86]]s में था। यदि किसी परिचालन के लिए अधिक रजिस्टर उपलब्ध नहीं हैं, तो [[आवंटन पंजीबद्ध करें|संकलक को रजिस्टर से मेमोरी]] (या मेमोरी टू रजिस्टर) में प्रतिलिपि बनानी चाहिए, जिसमें समय लगता है (रजिस्टर एक्सेस करने के लिए काफी तेज हैं)। यद्यपि, सर्वर वर्चुअल मशीन ने [[ग्राफ रंगना|कलर-ग्राफ़]] एलोकेटर का उपयोग किया और इसमें कोई समस्या नहीं थी।
@@ Line 114: / Line 122: @@
 सन के जेडीके 6 में रजिस्टर आवंटन का एक अनुकूलन प्रस्तुत किया गया था;<ref>[http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6320351 Bug report: new register allocator, fixed in Mustang (JDK 6) b59]</ref> यह तब खंडों में एक ही रजिस्टर का उपयोग करना संभव था (जब लागू हो), मेमोरी तक पहुंच को कम करना। इसके कारण कुछ बेंचमार्क में लगभग 60 प्रतिशत की वृद्धि दर्ज की गई। <ref>[http://weblogs.java.net/blog/2005/11/10/mustangs-hotspot-client-gets-58-faster Mustang's HotSpot Client gets 58% faster!] {{Webarchive|url=https://web.archive.org/web/20120305215143/http://weblogs.java.net/blog/2005/11/10/mustangs-hotspot-client-gets-58-faster |date=March 5, 2012 }} in Osvaldo Pinali Doederlein's Blog at java.net</ref>
 ==== वर्ग डेटा शेयरिंग ====
-वर्ग डेटा शेयरिंग (जिसे सन द्वारा सीडीएस कहा जाता है) एक तंत्र है जो जावा अनुप्रयोगों के लिए स्टार्टअप समय को कम करता है, और [[स्मृति पदचिह्न|मेमोरी फुटप्रिंट]] को भी कम करता है। जब [[जावा क्रम पर्यावरण]] स्थापित होता है, तो इंस्टॉलर सिस्टम जेएआर फ़ाइल से वर्गों का एक सेट लोड करता है (जेएआर फ़ाइल जिसमें सभी जावा वर्ग पुस्तकालय होती है, जिसे आरटी.जेएआर कहा जाता है) निजी आंतरिक प्रतिनिधित्व में, और उस प्रतिनिधित्व को फ़ाइल में डंप करता है, जिसे "साझा संग्रह" कहा जाता है। बाद के जेवीएम विक्रमों के दौरान, यह साझा संग्रह [[मेमोरी-मैप की गई फ़ाइल|मेमोरी-मैप्ड]] है, उन वर्गों को लोड करने की लागत को बचाता है और इन वर्गों के लिए जेवीएम के मेटाडेटा को एकाधिक जेवीएम प्रक्रियाओं के बीच साझा करने की अनुमति देता है।<ref>[http://java.sun.com/j2se/1.5.0/docs/guide/vm/class-data-sharing.html Class Data Sharing] at java.sun.com</ref>
+वर्ग डेटा शेयरिंग (जिसे सन द्वारा सीडीएस कहा जाता है) एक तंत्र है जो जावा अनुप्रयोगों के लिए स्टार्टअप समय को कम करता है, और [[स्मृति पदचिह्न|मेमोरी फुटप्रिंट]] को भी कम करता है। जब [[जावा क्रम पर्यावरण]] स्थापित होता है, तो इंस्टॉलर प्रणालियों जेएआर फ़ाइल से वर्गों का एक सेट लोड करता है (जेएआर फ़ाइल जिसमें सभी जावा वर्ग पुस्तकालय होती है, जिसे आरटी.जेएआर कहा जाता है) निजी आंतरिक प्रतिनिधित्व में, और उस प्रतिनिधित्व को फ़ाइल में डंप करता है, जिसे "साझा संग्रह" कहा जाता है। बाद के जेवीएम विक्रमों के दौरान, यह साझा संग्रह [[मेमोरी-मैप की गई फ़ाइल|मेमोरी-मैप्ड]] है, उन वर्गों को लोड करने की लागत को बचाता है और इन वर्गों के लिए जेवीएम के मेटाडेटा को एकाधिक जेवीएम प्रक्रियाओं के बीच साझा करने की अनुमति देता है।<ref>[http://java.sun.com/j2se/1.5.0/docs/guide/vm/class-data-sharing.html Class Data Sharing] at java.sun.com</ref>
 छोटे प्रोग्रामों के लिए स्टार्ट-अप समय में संबंधित सुधार अधिक स्पष्ट होता है।<ref>[http://www.artima.com/forums/flat.jsp?forum=121&thread=56613 Class Data Sharing in JDK 1.5.0] in Java Buzz Forum
@@ Line 120: / Line 128: @@
 == प्रदर्शन में सुधार का इतिहास ==
 {{Further|जावा संस्करण इतिहास}}
-यहां सूचीबद्ध सुधारों के अलावा, जावा के प्रत्येक रिलीज ने जेवीएम और जावा [[अप्लिकेशन प्रोग्रामिंग अंतरफलक|एप्लिकेशन प्रोग्रामिंग इंटरफेस]] (एपीआई) में एकाधिक प्रदर्शन सुधार प्रस्तुत किए।
+यहां सूचीबद्ध सुधारों के अलावा, जावा के प्रत्येक रिलीज ने जेवीएम और जावा [[अप्लिकेशन प्रोग्रामिंग अंतरफलक|विनियोग प्रोग्रामिंग इंटरफेस]] (एपीआई) में एकाधिक प्रदर्शन सुधार प्रस्तुत किए।
 जेडीके 1.1.6: पहला जस्ट-इन-टाइम संकलन ([[NortonLifeLock|नॉर्टनलाइफ लॉक]]' जेआईटी-संकलक)<ref name="symantec.com"/><ref name="symantec compiler">{{Cite web|last1=Mckay|first1=Niali|url=http://linxdigital.ca/java-four-times-faster-symantec-compiler.html|title=Java gets four times faster with new Symantec just-in-time compiler}}</ref>
@@ Line 142: / Line 150: @@
 'जावा 5 और जावा 6 के बीच प्रदर्शन में सुधार का सन ओवरव्यू' भी देखें।<ref>[http://java.sun.com/performance/reference/whitepapers/6_performance.html Java SE 6 Performance White Paper] at http://java.sun.com</ref>
 === जावा एसई 6 अपडेट 10 ===
-*जावा त्वरित स्टार्टर [[पेज कैश|डिस्क कैश]] पर ओएस स्टार्टअप पर जेआरई डेटा के भाग को पहले से लोड करके एप्लिकेशन स्टार्ट-अप समय को कम करता है।<ref name="jrecache">{{Cite web
+*जावा त्वरित स्टार्टर [[पेज कैश|डिस्क कैश]] पर ओएस स्टार्टअप पर जेआरई डेटा के भाग को पहले से लोड करके विनियोग स्टार्ट-अप समय को कम करता है।<ref name="jrecache">{{Cite web
 | url=http://java.sun.com/developer/technicalArticles/javase/consumerjre#Quickstarter
 | title=Consumer JRE: Leaner, Meaner Java Technology
@@ Line 149: / Line 157: @@
 | quote=''At the OS level, all of these megabytes have to be read from disk, which is a very slow operation. Actually, it's the seek time of the disk that's the killer; reading large files sequentially is relatively fast, but seeking the bits that we actually need is not.  So even though we only need a small fraction of the data in these large files for any particular application, the fact that we're seeking all over within the files means that there is plenty of disk activity.''
 |date= May 2007| access-date=July 27, 2007}}</ref>
-*जेआरई स्थापित नहीं होने पर वेब से एक्सेस किए गए एप्लिकेशन को निष्पादित करने के लिए आवश्यक प्लेटफॉर्म के भाग अब पहले डाउनलोड किए जाते हैं। पूर्ण जेआरई 12 एमबी है, एक सामान्य स्विंग एप्लिकेशन को प्रारम्भ करने के लिए केवल 4 एमबी डाउनलोड करने की आवश्यकता है। इसके बाद बाकी हिस्सों को बैकग्राउंड में डाउनलोड किया जाता है।<ref>{{Cite web
+*जेआरई स्थापित नहीं होने पर वेब से एक्सेस किए गए विनियोग को निष्पादित करने के लिए आवश्यक प्लेटफॉर्म के भाग अब पहले डाउनलोड किए जाते हैं। पूर्ण जेआरई 12 एमबी है, एक सामान्य स्विंग विनियोग को प्रारम्भ करने के लिए केवल 4 एमबी डाउनलोड करने की आवश्यकता है। इसके बाद बाकी हिस्सों को बैकग्राउंड में डाउनलोड किया जाता है।<ref>{{Cite web
 | url=http://java.sun.com/developer/technicalArticles/javase/consumerjre#JavaKernel
 | title=Consumer JRE: Leaner, Meaner Java Technology
@@ Line 188: / Line 196: @@
 |date= May 2006| access-date=May 30, 2008}}</ref>
 **क्लाइंट का उपयोग स्टार्टअप पर किया जाएगा (क्योंकि यह स्टार्टअप पर और छोटे अनुप्रयोगों के लिए अच्छा है),
-**सर्वर का उपयोग एप्लिकेशन के लंबे समय तक चलने के लिए किया जाएगा (क्योंकि यह इसके लिए क्लाइंट संकलक से बेहतर प्रदर्शन करता है)।
+**सर्वर का उपयोग विनियोग के लंबे समय तक चलने के लिए किया जाएगा (क्योंकि यह इसके लिए क्लाइंट संकलक से बेहतर प्रदर्शन करता है)।
 *मौजूदा समवर्ती कम-विराम कचरा संग्राहक (जिसे समवर्ती मार्क-स्वीप (सीएमएस) संग्राहक भी कहा जाता है) को एक नए संग्राहक द्वारा प्रतिस्थापित किया जाता है जिसे कचरा पहले (जी1) कहा जाता है ताकि समय के साथ लगातार ठहराव सुनिश्चित हो सके।<ref>{{Cite web
 | url=http://www.infoq.com/news/2008/05/g1
@@ Line 211: / Line 219: @@
 </ref>                                                                     .
 == अन्य भाषाओं की तुलना ==
-जावा प्रोग्राम के प्रदर्शन की वस्तुनिष्ठ तुलना और एक अन्य भाषा में लिखे गए समकक्ष जैसे कि C++ को सावधानीपूर्वक और सोच-समझकर निर्मित बेंचमार्क की आवश्यकता होती है जो समान कार्यों को पूरा करने वाले प्रोग्रामों की तुलना करता है। जावा के [[बाईटकोड]] संकलक का लक्ष्य प्लेटफॉर्म [[जावा मंच|जावा प्लेटफॉर्म]] है, और बायटेकोड को या तो जेवीएम द्वारा मशीन कोड में व्याख्या या संकलित किया जाता है। अन्य संकलक लगभग हमेशा एक विशिष्ट हार्डवेयर और सॉफ्टवेयर प्लेटफॉर्म को लक्षित करते हैं, मशीन कोड का उत्पादन करते हैं जो निष्पादन के दौरान वस्तुतः अपरिवर्तित रहेगा{{citation needed|reason=What are the real world, non-theoretical implications of this?|date=May 2016}}। इन दो अलग-अलग दृष्टिकोणों से बहुत भिन्न और कठिन-से-तुलना वाले परिदृश्य उत्पन्न होते हैं: स्थिर बनाम [[गतिशील संकलन]] और पुनर्संकलन, कार्यावधि वातावरण और अन्य के बारे में सटीक जानकारी की उपलब्धता।
+जावा प्रोग्राम के प्रदर्शन की वस्तुनिष्ठ तुलना और एक अन्य भाषा में लिखे गए समकक्ष जैसे कि C++ को सावधानीपूर्वक और सोच-समझकर निर्मित बेंचमार्क की आवश्यकता होती है जो समान कार्यों को पूरा करने वाले प्रोग्रामों की तुलना करता है। जावा के [[बाईटकोड]] संकलक का लक्ष्य प्लेटफॉर्म [[जावा मंच|जावा प्लेटफॉर्म]] है, और बायटेकोड को या तो जेवीएम द्वारा मशीन कोड में व्याख्या या संकलित किया जाता है। अन्य संकलक लगभग हमेशा एक विशिष्ट हार्डवेयर और सॉफ्टवेयर प्लेटफॉर्म को लक्षित करते हैं, मशीन कोड का उत्पादन करते हैं जो निष्पादन के दौरान वस्तुतः अपरिवर्तित रहेगा। इन दो अलग-अलग दृष्टिकोणों से बहुत भिन्न और कठिन-से-तुलना वाले परिदृश्य उत्पन्न होते हैं: स्थिर बनाम [[गतिशील संकलन]] और पुनर्संकलन, कार्यावधि वातावरण और अन्य के बारे में सटीक जानकारी की उपलब्धता।
 जावा वर्चुअल मशीन द्वारा जावा कोअधिकांशतः कार्यावधि पर समय-समय पर संकलित किया जाता है, लेकिन C++ के रूप में भी [[समय से पहले संकलन|समय-समय पर संकलित]] किया जा सकता है। जब सही समय पर संकलित किया जाता है, द [[कंप्यूटर भाषा बेंचमार्क गेम]] के माइक्रो-बेंचमार्क इसके प्रदर्शन के बारे में निम्नलिखित संकेत देते हैं:<ref>
@@ Line 254: / Line 262: @@
 === प्रोग्राम की गति ===
-बेंचमार्क अधिकांशतः छोटे संख्यात्मक रूप से गहन प्रोग्रामों के प्रदर्शन को मापते हैं। कुछ दुर्लभ वास्तविक जीवन के प्रोग्रामों में, जावा C से बेहतर प्रदर्शन करता है। एक उदाहरण जेक2 (मूल [[जीपीएल]] सी कोड का अनुवाद करके जावा में लिखा गया क्वेक II का एक क्लोन) का बेंचमार्क है। जावा 5.0 संस्करण अपने सी समकक्ष की तुलना में कुछ हार्डवेयर विन्यासों में बेहतर प्रदर्शन करता है।<ref>:260/250 [[Frame rate|frame/s]] versus 245 frame/s (see [http://www.bytonic.de/html/benchmarks.html benchmark])</ref>यद्यपि यह निर्दिष्ट नहीं किया गया है कि डेटा को कैसे मापा गया था (उदाहरण के लिए यदि 1997 में संकलित मूल क्वेक II निष्पादन योग्य का उपयोग किया गया था, जिसे खराब माना जा सकता है क्योंकि वर्तमान सी संकलक क्वेक के लिए बेहतर अनुकूलन प्राप्त कर सकते हैं), यह नोट करता है कि कैसे समान जावा स्रोत कोड केवल वीएम को अपडेट करने से गति में भारी वृद्धि हो सकती है, जो 100% स्थिर दृष्टिकोण के साथ हासिल करना असंभव है।
+बेंचमार्क अधिकांशतः छोटे संख्यात्मक रूप से गहन प्रोग्रामों के प्रदर्शन को मापते हैं। कुछ दुर्लभ वास्तविक जीवन के प्रोग्रामों में, जावा C से बेहतर प्रदर्शन करता है। एक उदाहरण जेक2 (मूल [[जीपीएल]] सी कोड का अनुवाद करके जावा में लिखा गया क्वेक II का एक क्लोन) का बेंचमार्क है। जावा 5.0 संस्करण अपने सी समकक्ष की तुलना में कुछ हार्डवेयर विन्यासों में बेहतर प्रदर्शन करता है।<ref>:260/250 [[Frame rate|frame/s]] versus 245 frame/s (see [http://www.bytonic.de/html/benchmarks.html benchmark])</ref>यद्यपि यह निर्दिष्ट नहीं किया गया है कि डेटा को कैसे मापा गया था (उदाहरण के लिए यदि 1997 में संकलित मूल क्वेक II निष्पादन योग्य का उपयोग किया गया था, जिसे खराब माना जा सकता है क्योंकि वर्तमान सी संकलक क्वेक के लिए बेहतर अनुकूलन प्राप्त कर सकते हैं), यह नोट करता है कि कैसे समान जावा स्रोत कोड केवल वीएम को अपडेट करने से गति में भारी वृद्धि हो सकती है, जो 100% स्थिर दृष्टिकोण के साथ प्राप्त  करना असंभव है।
-अन्य प्रोग्रामों के लिए, C++ समकक्ष जावा समकक्ष से काफी तेजी से चला सकता है, औरसामान्यतः करता है। 2011 में गूगल द्वारा किए गए एक बेंचमार्क ने C++ और जावा के बीच एक कारक 10 दिखाया।<ref>{{Cite journal |last1=Hundt |first1=Robert |title=Loop Recognition in C++/Java/Go/Scala |journal=Scala Days 2011 |location=Stanford, California |access-date=March 23, 2014 |url=https://days2011.scala-lang.org/sites/days2011/files/ws3-1-Hundt.pdf}}</ref> दूसरे चरम पर, एक 3डी मॉडलिंग एल्गोरिदम के साथ 2012 में किए गए एक अकादमिक बेंचमार्क ने [[जावा 6]] जेवीएम को विंडोज के तहत C++ की तुलना में 1.09 से 1.91 गुना धीमा दिखाया।<ref>{{cite web
+अन्य प्रोग्रामों के लिए, C++ समकक्ष जावा समकक्ष से काफी तेजी से चला सकता है, और सामान्यतः करता है। 2011 में गूगल द्वारा किए गए बेंचमार्क ने C++ और जावा के बीच एक कारक 10 को दिखाया।<ref>{{Cite journal |last1=Hundt |first1=Robert |title=Loop Recognition in C++/Java/Go/Scala |journal=Scala Days 2011 |location=Stanford, California |access-date=March 23, 2014 |url=https://days2011.scala-lang.org/sites/days2011/files/ws3-1-Hundt.pdf}}</ref> दूसरे चरम पर, एक 3डी मॉडलिंग एल्गोरिदम के साथ 2012 में किए गए एक शैक्षणिक बेंचमार्क ने [[जावा 6]] जेवीएम को विंडोज के तहत C++ की तुलना में 1.09 से 1.91 गुना धीमा दिखाया।<ref>{{cite web
 | url= http://www.best-of-robotics.org/pages/publications/gherardi12java.pdf
 | title=A Java vs. C++ performance evaluation: a 3D modeling benchmark
@@ Line 262: / Line 270: @@
 |author1=L. Gherardi |author2=D. Brugali |author3=D. Comotti | year= 2012
 | quote=''Using the Server compiler, which is best tuned for long-running applications, have instead demonstrated that Java is from 1.09 to 1.91 times slower(...)In conclusion, the results obtained with the server compiler and these important features suggest that Java can be considered a valid alternative to C++''
 | access-date= March 23, 2014}}</ref>
 कुछ अनुकूलन जो जावा और समान भाषाओं में संभव हैं, कुछ परिस्थितियों में C++ में संभव नहीं हो सकते हैं:
-*सी-स्टाइल पॉइंटर का उपयोग पॉइंटर्स का समर्थन करने वाली भाषाओं में अनुकूलन में बाधा डाल सकता है,
+*सी-शैली सूचक प्रयोग उन भाषाओं में अनुकूलन में बाधा डाल सकता है जो सूचकों का समर्थन करती हैं,
-*एस्केप एनालिसिस मेथड्स का उपयोग C++ में सीमित है, उदाहरण के लिए, क्योंकि एक C++ संकलक हमेशा यह नहीं जानता है कि पॉइंटर्स के कारण कोड के दिए गए खंडों में विषय को संशोधित किया जाएगा या नहीं,<ref group="note">Contention of this nature can be alleviated in C++ programs at the source code level by employing advanced methods such as custom [[Allocator (C++)|allocators]], exploiting precisely the kind of low-level coding complexity that Java was designed to conceal and encapsulate; however, this approach is rarely practical if not adopted (or at least anticipated) while the program remains under primary development.</ref>
+*एस्केप एनालिसिस विधियों का उपयोग C++ में सीमित है, उदाहरण के लिए, क्योंकि एक C++ संकलक हमेशा यह नहीं जानता है कि संकेतक के कारण कोड के दिए गए खंडों में विषय को संशोधित किया जाएगा या नहीं,<ref group="note">Contention of this nature can be alleviated in C++ programs at the source code level by employing advanced methods such as custom [[Allocator (C++)|allocators]], exploiting precisely the kind of low-level coding complexity that Java was designed to conceal and encapsulate; however, this approach is rarely practical if not adopted (or at least anticipated) while the program remains under primary development.</ref>
-*C++ के अतिरिक्त वर्चुअल-टेबल लुक-अप के कारण जावा व्युत्पन्न उदाहरण विधियों तक तेजी से पहुंच सकता है।यद्यपि, C++ में गैर-वर्चूअल विधियां वी-टेबल प्रदर्शन बाधाओं से पीड़ित नहीं होती हैं, और इस प्रकार जावा के समान प्रदर्शन प्रदर्शित करती हैं।
+*जावा C++ के अतिरिक्त वर्चुअल-तालिका लुक-अप के कारण व्युत्पन्न वर्चुअल विधियों तक तेजी से पहुंच प्राप्त कर सकता है।  यद्यपि, C++ में गैर-वर्चूअल विधियां वी-तालिका प्रदर्शन बाधाओं से पीड़ित नहीं होती हैं, और इस प्रकार जावा के समान प्रदर्शन प्रदर्शित करती हैं।
-जेवीएम प्रोसेसर विशिष्ट अनुकूलन या [[इनलाइन विस्तार]] करने में भी सक्षम है। और, पहले से संकलित या इनलाइन किए गए कोड को डी-ऑप्टिमाइज करने की क्षमता कभी-कभी बाहरी पुस्तकालय कार्यों मेंसम्मिलित होने पर स्थिर रूप से टाइप की गई भाषाओं द्वारा किए गए अनुकूलन की तुलना में अधिक आक्रामक अनुकूलन करने की अनुमति देती है।<ref>{{Cite web
+जेवीएम प्रोसेसर विशिष्ट अनुकूलन या [[इनलाइन विस्तार|अपंक्तिबद्ध विस्तार]] का प्रदर्शन करने में सक्षम है। और, पहले से संकलित या अपंक्तिबद्ध किए गए कोड को डी-अनुकूलित करने की क्षमता कभी-कभी इसे द्वारा निष्पादित किए गए कोड की तुलना में अधिक आक्रामक अनुकूलन निष्पादित करने की अनुमति देती है<ref>{{Cite web
 | url=http://java.sun.com/developer/technicalArticles/Networking/HotSpot/inlining.html
 | title=The Java HotSpot Performance Engine: Method Inlining Example
@@ Line 303: / Line 311: @@
 | date=July 1, 2005
 | access-date=January 18, 2011}}</ref> तुलनीय C++ प्रोग्राम के समान प्रदर्शन है
-*ऐरे<ref>{{Cite web
+*सरणियाँ<ref>{{Cite web
 | url=http://www.ddj.com/java/184401976?pgno=19
 | title=Microbenchmarking C++, C#, and Java: Array
@@ Line 314: / Line 322: @@
 | publisher=[[Dr. Dobb's Journal]]
 | date=July 1, 2005
 | access-date=January 18, 2011}}</ref>
 ----
 ;टिप्पणियाँ
 {{Reflist|group=note}}
-=== मल्टी-कोर प्रदर्शन ===
+=== बहु-कोर प्रदर्शन ===
-मल्टी-कोर सिस्टम पर जावा अनुप्रयोगों की मापनीयता और प्रदर्शन वस्तु आवंटन दर द्वारा सीमित है। इस प्रभाव को कभी-कभी "आवंटन दीवार" कहा जाता है।<ref>Yi Zhao, Jin Shi, Kai Zheng, Haichuan Wang, Haibo Lin and Ling Shao, [http://portal.acm.org/citation.cfm?id=1640116 Allocation wall: a limiting factor of Java applications on emerging multi-core platforms], Proceedings of the 24th ACM SIGPLAN conference on Object oriented programming systems languages and applications, 2009.</ref>यद्यपि, व्यवहार में, आधुनिक कचरा संग्राहक एल्गोरिदम कचरा संग्रह करने के लिए एकाधिक कोर का उपयोग करते हैं, जो कुछ हद तक इस समस्या को कम करता है। कुछ गारबेज संग्राहक प्रति सेकंड एक गीगाबाइट से अधिक की आवंटन दर को बनाए रखने की सूचना देते हैं,<ref>[http://www.azulsystems.com/sites/default/files/images/c4_paper_acm_0.pdf C4: The Continuously Concurrent Compacting Collector]</ref> और जावा-आधारित सिस्टम मौजूद हैं जिन्हें एकाधिक सैकड़ों सीपीयू कोर और ढेर के आकार को एकाधिक सौ जीबी तक बढ़ाने में कोई समस्या नहीं है।<ref>[https://www.theregister.co.uk/2007/06/15/azul_releases_7200_systems/ Azul bullies Java with 768 core machine]</ref>
+बहु-कोर प्रणालियों पर जावा अनुप्रयोगों की मापनीयता और प्रदर्शन वस्तु आवंटन दर द्वारा सीमित है। इस प्रभाव को कभी-कभी "आवंटन दीवार" कहा जाता है।<ref>Yi Zhao, Jin Shi, Kai Zheng, Haichuan Wang, Haibo Lin and Ling Shao, [http://portal.acm.org/citation.cfm?id=1640116 Allocation wall: a limiting factor of Java applications on emerging multi-core platforms], Proceedings of the 24th ACM SIGPLAN conference on Object oriented programming systems languages and applications, 2009.</ref>यद्यपि, व्यवहार में, आधुनिक कचरा संग्राहक एल्गोरिदम कचरा संग्रह करने के लिए एकाधिक कोर का उपयोग करते हैं, जो कुछ हद तक इस समस्या को कम करता है। कुछ कचरा संग्राहक प्रति सेकंड एक गीगाबाइट से अधिक की आवंटन दर को बनाए रखने की सूचना देते हैं,<ref>[http://www.azulsystems.com/sites/default/files/images/c4_paper_acm_0.pdf C4: The Continuously Concurrent Compacting Collector]</ref> और जावा-आधारित प्रणालियों मौजूद हैं जिन्हें एकाधिक सैकड़ों सीपीयू कोर और ढेर के आकार को एकाधिक सौ जीबी तक बढ़ाने में कोई समस्या नहीं है।<ref>[https://www.theregister.co.uk/2007/06/15/azul_releases_7200_systems/ Azul bullies Java with 768 core machine]</ref>
 जावा में स्वचालित मेमोरी प्रबंधन लॉकलेस और अपरिवर्तनीय डेटा संरचनाओं के कुशल उपयोग की अनुमति देता है जो किसी प्रकार के कचरा संग्रह के बिना लागू करने के लिए अत्यंत कठिन या कभी-कभी असंभव हैं।{{citation needed|date=September 2018}} जावा अपने मानक पुस्तकालय में ऐसी एकाधिक उच्च-स्तरीय संरचनाएं प्रदान करता है। जावा.यूटीआईआई.कन्करन्ट पैकेज में, जबकि C या C++ जैसी उच्च प्रदर्शन प्रणालियों के लिए ऐतिहासिक रूप से उपयोग की जाने वाली एकाधिक भाषाओं में अभी भी उनकी कमी है।{{citation needed|date=September 2017}}
 === स्टार्टअप समय ===
 जावा स्टार्टअप समय अधिकांशतः C, C++, पर्ल या पायथन सहित एकाधिक भाषाओं की तुलना में बहुत धीमा होता है, क्योंकि उपयोग किए जाने से पहले एकाधिक वर्गों (और सबसे पहले प्लेटफ़ॉर्म वर्ग पुस्तकालय से सभी वर्गों) को लोड किया जाना चाहिए।
@@ Line 329: / Line 337: @@
 | url=http://www.codeproject.com/KB/dotnet/RuntimePerformance.aspx
 | title=Benchmark start-up and system performance for .Net, Mono, Java, C++ and their respective UI
 | date=September 2, 2010}}</ref>
-ऐसा लगता है कि स्टार्टअप का अधिकांश समय जेवीएम इनिशियलाइज़ेशन या वर्ग भारण के बजाय इनपुट-आउटपुट (IO) बाउंड ऑपरेशंस के कारण होता है (rt.जेएआर वर्ग डेटा फ़ाइल अकेले 40 एमबी है और जेवीएम को इस बड़ी फ़ाइल में बहुत अधिक डेटा की तलाश करनी चाहिए)<ref name="jrecache" /> कुछ परीक्षणों से पता चला है कियद्यपि नई स्प्लिट बायटेकोड सत्यापन विधि ने वर्ग भारण में लगभग 40% सुधार किया है, यह बड़े प्रोग्रामों के लिए केवल 5% स्टार्टअप सुधार का एहसास हुआ।<ref>{{Cite web
+ऐसा लगता है कि स्टार्टअप का अधिकांश समय जेवीएम प्रारंभीकरण या वर्ग भारण के बजाय इनपुट-आउटपुट (IO) सीमित संचालन के कारण होता है (अकेले rt.जेएआर वर्ग डेटा फ़ाइल 40 एमबी है और जेवीएम को इस बड़ी फ़ाइल में बहुत अधिक डेटा की तलाश करनी चाहिए)<ref name="jrecache" /> कुछ परीक्षणों से पता चला है कि यद्यपि नई विभाजन बायटेकोड सत्यापन विधि ने वर्ग भारण में लगभग 40% की वृद्धि की, इसने केवल बड़े प्रोग्रामों के लिए केवल 5% स्टार्टअप सुधार का संपादित किया।<ref>{{Cite web
   |url         = http://forums.java.net/jive/thread.jspa?messageID=94530
   |title       = How fast is the new verifier?
@@ Line 346: / Line 354: @@
 जावा एसई 6 अपडेट 10 से प्रारम्भ होकर, सन जेआरई एक त्वरित स्टार्टर के साथ आता है जो डिस्क के बजाय डिस्क कैश से डेटा प्राप्त करने के लिए ओएस स्टार्टअप पर वर्ग डेटा पहले से लोड करता है।
-[[एक्सेलसियर जेट]] दूसरी तरफ से समस्या का समाधान करता है। इसका स्टार्टअप ऑप्टिमाइज़र उस डेटा की मात्रा को कम करता है जिसे डिस्क से एप्लिकेशन स्टार्टअप पर पढ़ा जाना चाहिए, और पढ़ने को अधिक अनुक्रमिक बनाता है।
+[[एक्सेलसियर जेट]] दूसरी तरफ से समस्या का समाधान करता है। इसका स्टार्टअप ऑप्टिमाइज़र उस डेटा की मात्रा को कम करता है जिसे डिस्क से विनियोग स्टार्टअप पर पढ़ा जाना चाहिए, और पढ़ने को अधिक अनुक्रमिक बनाता है।
-नवंबर 2004 में, नेलगन, एक "क्लाइंट, प्रोटोकॉल, और सर्वर जो कमांड लाइन से बिना जेवीएम स्टार्टअप ओवरहेड के जावा प्रोग्राम चलाने के लिए" सार्वजनिक रूप से जारी किया गया था।<ref>[http://martiansoftware.com/nailgun/ Nailgun]</ref> बिना जेवीएम स्टार्टअप ओवरहेड के एक या एक से अधिक जावा एप्लिकेशन चलाने के लिए पहली बार [[स्क्रिप्ट (कंप्यूटिंग)]] के लिए एक जेवीएम को [[डेमन (कंप्यूटिंग)]] के रूप में उपयोग करने का विकल्प प्रस्तुत करना। नेलगुन डेमन असुरक्षित है: "सभी प्रोग्राम सर्वर के समान अनुमतियों के साथ चलाए जाते हैं"। जहाँ बहु-उपयोगकर्ता सुरक्षा की आवश्यकता होती है, विशेष सावधानियों के बिना नेलगन अनुपयुक्त है। लिपियों जहां प्रति-अनुप्रयोग जेवीएम स्टार्टअप संसाधन उपयोग पर हावी है, परिमाण कार्यावधि प्रदर्शन में सुधार के एक से दो क्रम देखें।<ref>The Nailgun [http://martiansoftware.com/nailgun/background.html Background] page demonstrates "''best case scenario''" speedup of 33 times (for scripted [["Hello, World!" program]]s i.e., short-run programs).</ref>
+नवंबर 2004 में, नेलगन, "क्लाइंट, प्रोटोकॉल, और जेवीएम स्टार्टअप के ऊपर सर्वर जो आदेश पंक्ति से जावा प्रोग्राम चलाने के लिए" सार्वजनिक रूप से जारी किया गया था।'<ref>[http://martiansoftware.com/nailgun/ Nailgun]</ref> बिना जेवीएम स्टार्टअप ओवरहेड के एक या एक से अधिक जावा विनियोग चलाने के लिए पहली बार [[स्क्रिप्ट (कंप्यूटिंग)]] के लिए एक जेवीएम को [[डेमन (कंप्यूटिंग)]] के रूप में उपयोग करने का विकल्प प्रस्तुत करना। नेलगुन डेमन असुरक्षित है: "सभी प्रोग्राम सर्वर के समान अनुमतियों के साथ चलाए जाते हैं"। जहाँ बहु-उपयोगकर्ता सुरक्षा की आवश्यकता होती है, विशेष सावधानियों के बिना नेलगन अनुपयुक्त है। लिपियों जहां प्रति-अनुप्रयोग जेवीएम स्टार्टअप संसाधन उपयोग पर हावी है, परिमाण कार्यावधि प्रदर्शन में सुधार के एक से दो क्रम देखें।<ref>The Nailgun [http://martiansoftware.com/nailgun/background.html Background] page demonstrates "''best case scenario''" speedup of 33 times (for scripted [["Hello, World!" program]]s i.e., short-run programs).</ref>
 === मेमोरी उपयोग ===
 जावा मेमोरी का उपयोग C++ के मेमोरी उपयोग से काफी अधिक है क्योंकि:
@@ Line 355: / Line 363: @@
 *मॉलोक और नए के विपरीत, ढेर के आकार में वृद्धि के साथ कचरा संग्रह का औसत प्रदर्शन शून्य के करीब पहुंच जाता है (अधिक सटीक रूप से, एक सीपीयू चक्र)।<ref>https://www.youtube.com/watch?v=M91w0SBZ-wc : Understanding Java Garbage Collection - a talk by Gil Tene at JavaOne</ref>
 *[[जावा क्लास लाइब्रेरी|जावा वर्ग पुस्तकालय]] के कुछ हिस्सों को प्रोग्राम के निष्पादन से पहले भारण करना चाहिए (कम से कम एक प्रोग्राम के भीतर उपयोग की जाने वाली कक्षाएं)।<ref>{{Cite web|url=http://www.tommti-systems.de/go.html?http://www.tommti-systems.de/main-Dateien/reviews/languages/benchmarks.html|title = .: ToMMTi-Systems :: Hinter den Kulissen moderner 3D-Hardware}}</ref> यह छोटे अनुप्रयोगों के लिए एक महत्वपूर्ण मेमोरी ओवरहेड की ओर ले जाता है।{{citation needed|date=January 2012}}
-*जावा बाइनरी और मूल पुनर्संकलन दोनोंसामान्यतः मेमोरी में होंगे।
+*जावा बाइनरी और मूल पुनर्संकलन दोनों सामान्यतः मेमोरी में होंगे।
 *वर्चुअल मशीन पर्याप्त मेमोरी का उपयोग करती है।
 *जावा में, एक समग्र वस्तु (कक्षा ए जो बी और सी के उदाहरणों का उपयोग करती है) बी और सी के आवंटित उदाहरणों के संदर्भों का उपयोग करके बनाई गई है। C++ में इस प्रकार के संदर्भों की मेमोरी और प्रदर्शन लागत से बचा जा सकता है जब बी और सी का उदाहरण /या C, A के भीतर मौजूद है।
-ज्यादातर मामलों में जावा की वर्चुअल मशीन, वर्ग भारण और स्वचालित मेमोरी रीसाइजिंग के बड़े ओवरहेड के कारण C++ एप्लिकेशन समकक्ष जावा एप्लिकेशन की तुलना में कम मेमोरी का उपभोग करेगा। उन प्रोग्रामों के लिए जिनमें भाषाओं और कार्यावधि परिवेशों के बीच चयन करने के लिए मेमोरी एक महत्वपूर्ण कारक है, एक लागत/लाभ विश्लेषण की आवश्यकता है।
+ज्यादातर मामलों में जावा की वर्चुअल मशीन, वर्ग भारण और स्वचालित मेमोरी रीसाइजिंग के बड़े ओवरहेड के कारण C++ विनियोग समकक्ष जावा विनियोग की तुलना में कम मेमोरी का उपभोग करेगा। उन प्रोग्रामों के लिए जिनमें भाषाओं और कार्यावधि परिवेशों के बीच चयन करने के लिए मेमोरी एक महत्वपूर्ण कारक है, एक लागत/लाभ विश्लेषण की आवश्यकता है।
 === त्रिकोणमितीय फलन ===
-त्रिकोणमितीय कार्यों का प्रदर्शन सी की तुलना में खराब है, क्योंकि जावा में गणितीय संचालन के परिणामों के लिए सख्त विनिर्देश हैं, जो अंतर्निहित हार्डवेयर कार्यान्वयन के अनुरूप नहीं हो सकते हैं।<ref>{{Cite web
+त्रिकोणमितीय फलनों का प्रदर्शन C की तुलना में खराब है, क्योंकि जावा में गणितीय संचालन के परिणामों के लिए सख्त विनिर्देश हैं, जो अंतर्निहित हार्डवेयर कार्यान्वयन के अनुरूप नहीं हो सकते हैं।<ref>{{Cite web
   | url= http://java.sun.com/javase/6/docs/api/java/lang/Math.html
   | title= Math (Java Platform SE 6)
@@ Line 390: / Line 398: @@
   | archive-date=October 11, 2018
   | url-status=dead
   }}</ref>{{clarify|date=April 2016}}
 === जावा मूल इंटरफ़ेस ===
 [[जावा मूल इंटरफ़ेस]] एक उच्च ओवरहेड का आह्वान करता है, जिससे जेवीएम और मूल कोड पर चलने वाले कोड के बीच की सीमा को पार करना महंगा हो जाता है।<ref>{{Cite web
@@ Line 418: / Line 426: @@
 }}{{dead link|date=November 2017 |bot=InternetArchiveBot |fix-attempted=yes }}</ref>
 === यूजर इंटरफेस ===
-[[स्विंग (जावा)]] को मूल [[विजेट टूलकिट]] की तुलना में धीमा माना गया है, क्योंकि यह विजेट के प्रतिपादन को शुद्ध जावा 2डी [[एपीआई]] को दर्शाता है।यद्यपि, स्विंग बनाम [[मानक विजेट टूलकिट]] के प्रदर्शन की तुलना करने वाले बेंचमार्क, जो ऑपरेटिंग सिस्टम के मूल जीयूआई पुस्तकालयों को प्रतिपादन का प्रतिनिधित्व करते हैं, कोई स्पष्ट विजेता नहीं दिखाते हैं, और परिणाम काफी हद तक संदर्भ और वातावरण पर निर्भर करते हैं।<ref>{{Cite web
+[[स्विंग (जावा)]] को मूल [[विजेट टूलकिट]] की तुलना में धीमा माना गया है, क्योंकि यह विजेट के प्रतिपादन को स्पष्ट जावा 2डी [[एपीआई]] को दर्शाता है।यद्यपि, स्विंग बनाम [[मानक विजेट टूलकिट]] के प्रदर्शन की तुलना करने वाले बेंचमार्क, जो ऑपरेटिंग प्रणालियों के मूल जीयूआई पुस्तकालयों को प्रतिपादन का प्रतिनिधित्व करते हैं, कोई स्पष्ट विजेता नहीं दिखाता हैं, और परिणाम संदर्भ और वातावरण पर काफी हद तक निर्भर करते हैं।<ref>{{Cite web
   |url          = http://cosylib.cosylab.com/pub/CSS/DOC-SWT_Vs._Swing_Performance_Comparison.pdf
   |title        = SWT Vs. Swing Performance Comparison
@@ Line 431: / Line 439: @@
   |url-status     = dead
   |df           = dmy-all
-}}</ref> इसके अतिरिक्त, स्विंग को बदलने के उद्देश्य से नया [[JavaFX|जावा एफएक्स]] ढांचा, स्विंग के एकाधिक अंतर्निहित मुद्दों को संबोधित करता है।
+}}</ref> इसके अतिरिक्त, स्विंग को बदलने के उद्देश्य से नया [[JavaFX|जावा एफएक्स]] ढांचा, स्विंग के एकाधिक अंतर्निहित मुद्दों को संबोधित करता है।                                  स्विंग को मूल विजेट टूलकिट की तुलना में धीमा माना गया है, क्योंकि यह स्पष्ट जावा 2D API पर विजेट्स का रेंडरिंग डेलिगेट्स करता है. हालांकि, बेंचमार्क स्विंग के प्रदर्शन बनाम मानक विजेट टूलकिट की तुलना करते हैं, जो ऑपरेटिंग सिस्टम के मूल GUI लाइब्रेरीज़ में रेंडरिंग प्रतिनिधियों को प्रस्तुत करता है, कोई स्पष्ट विजेता नहीं दिखाता है, और परिणाम संदर्भ और वातावरण पर काफी निर्भर करते हैं।[72] Addiaticialarate, नया जावाfx फ़्रेमवर्क, स्विंग को बदलने के इरादे से, स्विंग की कई निहित समस्याओं पर ध्यान देता है।
 === उच्च प्रदर्शन कंप्यूटिंग के लिए प्रयोग ===
@@ Line 441: / Line 449: @@
 |date= August 2008 |access-date=September 9, 2008}}</ref>
-यद्यपि, जावा में लिखे गए उच्च प्रदर्शन वाले कंप्यूटिंग अनुप्रयोगों ने बेंचमार्क प्रतियोगिताओं में जीत हासिल की है। 2008,<ref>{{Cite web
+यद्यपि, जावा में लिखे गए उच्च प्रदर्शन वाले कंप्यूटिंग अनुप्रयोगों ने बेंचमार्क प्रतियोगिताओं में जीत प्राप्त  की है। 2008,<ref>{{Cite web
   |url         = http://developer.yahoo.net/blogs/hadoop/2008/07/apache_hadoop_wins_terabyte_sort_benchmark.html
   |title       = Apache Hadoop Wins Terabyte Sort Benchmark
@@ Line 469: / Line 477: @@
 | access-date=September 8, 2010
 | publisher=[[CNET.com]]}}
-</ref> एक अपाचे [[Hadoop|हडूप]] (जावा में लिखा गया एक ओपन-सोर्स हाई परफॉर्मेंस कंप्यूटिंग प्रोजेक्ट) आधारित क्लस्टर एक टेराबाइट और पेटाबाइट पूर्णांकों को सबसे तेजी से सॉर्ट करने में सक्षम था। यद्यपि, प्रतिस्पर्धी प्रणालियों का हार्डवेयर सेटअप निश्चित नहीं था।<ref>{{cite web
+</ref> एक अपाचे [[Hadoop|हडूप]] (जावा में लिखा गया एक ओपन-सोर्स हाई परफॉर्मेंस कंप्यूटिंग प्रोजेक्ट) आधारित क्लस्टर एक टेराबाइट और पेटाबाइट पूर्णांकों को सबसे तेजी से वर्गीकृत करने में सक्षम था। यद्यपि, प्रतिस्पर्धी प्रणालियों का हार्डवेयर सेटअप निश्चित नहीं किया गया था।<ref>{{cite web
   | url=http://sortbenchmark.org/
   | title=Sort Benchmark Home Page
@@ Line 480: / Line 488: @@
   | first=Grzegorz
   | last=Czajkowski
 }}</ref>
 === प्रोग्रामिंग प्रतियोगिता में ===
-जावा में प्रोग्राम अन्य संकलित भाषाओं की तुलना में धीमी गति से प्रारम्भ होते हैं।<ref>{{Cite web |url=http://topcoder.com/home/tco10/2010/06/08/algorithms-problem-writing/ |title=TCO10 |access-date=June 21, 2010 |archive-url=https://web.archive.org/web/20101018212921/http://topcoder.com/home/tco10/2010/06/08/algorithms-problem-writing/ |archive-date=October 18, 2010 |url-status=dead |df=dmy-all }}</ref><ref>{{cite web | url=http://acm.timus.ru/help.aspx?topic=java&locale=en | title=How to write Java solutions @ Timus Online Judge }}</ref> इस प्रकार, कुछ ऑनलाइन जज सिस्टम, विशेष रूप से चीनी विश्वविद्यालयों द्वारा होस्ट किए गए, जावा प्रोग्रामों के लिए लंबी समय सीमा का उपयोग करते हैं<ref>{{cite web | url=http://acm.pku.edu.cn/JudgeOnline/faq.htm#q11 | title=FAQ }}</ref><ref>{{Cite web |url=http://acm.tju.edu.cn/toj/faq.html#qj |title=FAQ &#124; TJU ACM-ICPC Online Judge |access-date=May 25, 2010 |archive-url=https://web.archive.org/web/20100629135921/http://acm.tju.edu.cn/toj/faq.html#qj |archive-date=June 29, 2010 |url-status=dead |df=mdy-all }}</ref><ref>{{cite web | url=http://www.codechef.com/wiki/faq#How_does_the_time_limit_work | title=FAQ &#124; CodeChef }}</ref><ref>{{Cite web |url=http://acm.xidian.edu.cn/land/faq |title=HomePage of Xidian Univ. Online Judge |access-date=November 13, 2011 |archive-url=https://web.archive.org/web/20120219004452/http://acm.xidian.edu.cn/land/faq |archive-date=February 19, 2012 |url-status=dead |df=dmy-all }}</ref><ref>{{cite web | url=http://poj.org/faq.htm#q9 | title=FAQ }}</ref> जावा का उपयोग करने वाले प्रतियोगियों के लिए निष्पक्ष होना।
+जावा में प्रोग्राम अन्य संकलित भाषाओं की तुलना में धीमी गति से प्रारम्भ होते हैं।<ref>{{Cite web |url=http://topcoder.com/home/tco10/2010/06/08/algorithms-problem-writing/ |title=TCO10 |access-date=June 21, 2010 |archive-url=https://web.archive.org/web/20101018212921/http://topcoder.com/home/tco10/2010/06/08/algorithms-problem-writing/ |archive-date=October 18, 2010 |url-status=dead |df=dmy-all }}</ref><ref>{{cite web | url=http://acm.timus.ru/help.aspx?topic=java&locale=en | title=How to write Java solutions @ Timus Online Judge }}</ref> इस प्रकार, कुछ ऑनलाइन जज प्रणालियों, विशेष रूप से चीनी विश्वविद्यालयों द्वारा आयोजन किए गए, जावा प्रोग्रामों के लिए लंबी समय सीमा का उपयोग करते हुए प्रतियोगी के निष्पक्ष होने के लिए करते हैं।<ref>{{cite web | url=http://acm.pku.edu.cn/JudgeOnline/faq.htm#q11 | title=FAQ }}</ref><ref>{{Cite web |url=http://acm.tju.edu.cn/toj/faq.html#qj |title=FAQ &#124; TJU ACM-ICPC Online Judge |access-date=May 25, 2010 |archive-url=https://web.archive.org/web/20100629135921/http://acm.tju.edu.cn/toj/faq.html#qj |archive-date=June 29, 2010 |url-status=dead |df=mdy-all }}</ref><ref>{{cite web | url=http://www.codechef.com/wiki/faq#How_does_the_time_limit_work | title=FAQ &#124; CodeChef }}</ref><ref>{{Cite web |url=http://acm.xidian.edu.cn/land/faq |title=HomePage of Xidian Univ. Online Judge |access-date=November 13, 2011 |archive-url=https://web.archive.org/web/20120219004452/http://acm.xidian.edu.cn/land/faq |archive-date=February 19, 2012 |url-status=dead |df=dmy-all }}</ref><ref>{{cite web | url=http://poj.org/faq.htm#q9 | title=FAQ }}</ref>
 == यह भी देखें ==
@@ Line 510: / Line 518: @@
 {{DEFAULTSORT:Java Performance}}
+[[Category:All articles with dead external links|Java Performance]]
+[[Category:All articles with unsourced statements|Java Performance]]
+[[Category:Articles with dead external links from November 2017|Java Performance]]
+[[Category:Articles with hatnote templates targeting a nonexistent page|Java Performance]]
+[[Category:Articles with invalid date parameter in template|Java Performance]]
+[[Category:Articles with permanently dead external links|Java Performance]]
+[[Category:Articles with unsourced statements from January 2012|Java Performance]]
+[[Category:Articles with unsourced statements from September 2017|Java Performance]]
+[[Category:Articles with unsourced statements from September 2018|Java Performance]]
+[[Category:Collapse templates|Java Performance]]
+[[Category:Lua-based templates|Java Performance]]
+[[Category:Navigational boxes| ]]
+[[Category:Navigational boxes without horizontal lists|Java Performance]]
+[[Category:Pages with empty portal template|Java Performance]]
+[[Category:Pages with script errors|Java Performance]]
+[[Category:Portal-inline template with redlinked portals|Java Performance]]
+[[Category:Portal templates with redlinked portals|Java Performance]]
+[[Category:Sidebars with styles needing conversion|Java Performance]]
+[[Category:Template documentation pages|Documentation/doc]]
+[[Category:Templates Vigyan Ready|Java Performance]]
+[[Category:Templates generating microformats|Java Performance]]
+[[Category:Templates that add a tracking category|Java Performance]]
+[[Category:Templates that are not mobile friendly|Java Performance]]
+[[Category:Templates that generate short descriptions|Java Performance]]
+[[Category:Templates using TemplateData|Java Performance]]
+[[Category:Webarchive template wayback links]]
+[[Category:Wikipedia articles needing clarification from April 2016|Java Performance]]
+[[Category:Wikipedia metatemplates|Java Performance]]

Anonymous

Search

जावा-परफॉरमेंस: Difference between revisions

Latest revision as of 13:58, 7 July 2023

वर्चूअल मशीन अनुकूलन पद्धतियाँ

जस्ट-इन-टाइम संकलन

अनुकूली अनुकूलन

कचरा संग्रह

अन्य अनुकूलन विधियां

संकुचित उफ़

विभाजन बाइटकोड सत्यापन

एस्केप एनालिसिस और लॉक कोर्सनिंग

आवंटन सुधार दर्ज करें

वर्ग डेटा शेयरिंग

प्रदर्शन में सुधार का इतिहास

जावा एसई 6 अपडेट 10

जावा 7

अन्य भाषाओं की तुलना

प्रोग्राम की गति

बहु-कोर प्रदर्शन

स्टार्टअप समय

मेमोरी उपयोग

त्रिकोणमितीय फलन

जावा मूल इंटरफ़ेस

यूजर इंटरफेस

उच्च प्रदर्शन कंप्यूटिंग के लिए प्रयोग

प्रोग्रामिंग प्रतियोगिता में

यह भी देखें

संदर्भ

बाहरी संबंध

Navigation

Wiki tools

Page tools

Other projects

Hidden categories