जावा-परफॉरमेंस

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

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

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

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

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

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

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

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

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

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

स्प्लिट-टाइम वेरिफिकेशन नाम की एक विधि, जिसे पहली बार जावा प्लेटफॉर्म, माइक्रो एडिशन (J2ME) में पेश किया गया था, जावा संस्करण 6 के बाद से जावा संस्करण इतिहास में उपयोग किया जाता है। यह जावा बाइटकोड के सत्यापन को दो चरणों में विभाजित करता है:
 * डिज़ाइन-टाइम - स्रोत से बायटेकोड तक एक वर्ग को संकलित करते समय
 * रनटाइम - कक्षा लोड करते समय।

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

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

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

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

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

जावा 6 से शुरू होकर, कोड ब्लॉक और ऑब्जेक्ट केवल जरूरत पड़ने पर ही लॉक होते हैं, इसलिए उपरोक्त मामले में, वर्चुअल मशीन वेक्टर ऑब्जेक्ट को बिल्कुल भी लॉक नहीं करेगी।

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

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

Sun के JDK 6 में रजिस्टर आवंटन का एक अनुकूलन पेश किया गया था; तब मेमोरी तक पहुंच को कम करते हुए ब्लॉक (जब लागू हो) में समान रजिस्टरों का उपयोग करना संभव था। इसके कारण कुछ बेंचमार्क में लगभग 60% का प्रदर्शन लाभ हुआ।

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

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

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

JDK 1.1.6: पहला जस्ट-इन-टाइम संकलन (NortonLifeLock's JIT-compiler)

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

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

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

जावा एसई 5.0: क्लास डेटा शेयरिंग

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

अन्य सुधार: 'जावा 5 और जावा 6 के बीच प्रदर्शन में सुधार का सन ओवरव्यू' भी देखें।
 * जावा ओपनजीएल जावा 2डी पाइपलाइन गति में सुधार
 * Java 2D प्रदर्शन में भी Java 6 में काफी सुधार हुआ है

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

 * जावा क्विक स्टार्टर डिस्क कैश पर ओएस स्टार्टअप पर जेआरई डेटा के हिस्से को प्रीलोड करके एप्लिकेशन स्टार्ट-अप समय को कम करता है।
 * जेआरई स्थापित नहीं होने पर वेब से एक्सेस किए गए एप्लिकेशन को निष्पादित करने के लिए आवश्यक प्लेटफॉर्म के हिस्से अब पहले डाउनलोड किए जाते हैं। पूर्ण जेआरई 12 एमबी है, एक सामान्य स्विंग एप्लिकेशन को शुरू करने के लिए केवल 4 एमबी डाउनलोड करने की आवश्यकता है। इसके बाद बाकी हिस्सों को बैकग्राउंड में डाउनलोड किया जाता है।
 * डिफ़ॉल्ट रूप से का व्यापक रूप से उपयोग करके  पर ग्राफ़िक्स प्रदर्शन में सुधार हुआ है, और जटिल Java 2D संचालन में तेजी लाने के लिए  (GPU) पर ्स का उपयोग करें।
 * डिफ़ॉल्ट रूप से Direct3D का व्यापक रूप से उपयोग करके विंडोज पर ग्राफिक्स के प्रदर्शन में सुधार हुआ है, और जटिल जावा 2डी संचालन में तेजी लाने के लिए ग्राफ़िक्स प्रोसेसिंग यूनिट (जीपीयू) पर शेडर्स का उपयोग करें।

जावा 7
जावा 7 के लिए कई प्रदर्शन सुधार जारी किए गए हैं: जावा 6 या जावा 7 के अपडेट के लिए भविष्य के प्रदर्शन सुधारों की योजना बनाई गई है:
 * दा विंची मशीन (मल्टी लैंग्वेज वर्चुअल मशीन) पर वर्तमान में किए गए प्रोटोटाइप कार्य के बाद गतिशील प्रोग्रामिंग भाषाओं के लिए JVM समर्थन प्रदान करें,
 * मल्टी कोर प्रोसेसर पर समांतर कंप्यूटिंग प्रबंधित करके मौजूदा समवर्ती पुस्तकालय को बढ़ाएं,
 * जेवीएम को एक ही सत्र में क्लाइंट और सर्वर जेआईटी कंपाइलर्स दोनों का उपयोग करने की अनुमति दें, जिसे टियरड कंपाइलिंग कहा जाता है:
 * क्लाइंट का उपयोग स्टार्टअप पर किया जाएगा (क्योंकि यह स्टार्टअप पर और छोटे अनुप्रयोगों के लिए अच्छा है),
 * सर्वर का उपयोग एप्लिकेशन के लंबे समय तक चलने के लिए किया जाएगा (क्योंकि यह इसके लिए क्लाइंट कंपाइलर से बेहतर प्रदर्शन करता है)।
 * मौजूदा समवर्ती कम-विराम कचरा संग्राहक (जिसे समवर्ती मार्क-स्वीप (CMS) संग्राहक भी कहा जाता है) को एक नए संग्राहक द्वारा प्रतिस्थापित किया जाता है जिसे कचरा पहले (G1) कहा जाता है ताकि समय के साथ लगातार ठहराव सुनिश्चित हो सके।

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

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

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

अन्य कार्यक्रमों के लिए, C++ समकक्ष जावा समकक्ष से काफी तेजी से चला सकता है, और आमतौर पर करता है। 2011 में Google द्वारा किए गए एक बेंचमार्क ने C++ और Java के बीच एक कारक 10 दिखाया। दूसरे चरम पर, एक 3डी मॉडलिंग एल्गोरिदम के साथ 2012 में किए गए एक अकादमिक बेंचमार्क ने जावा 6 जेवीएम को विंडोज के तहत C++ की तुलना में 1.09 से 1.91 गुना धीमा दिखाया।

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

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

जावा और C++ के बीच माइक्रोबेंचमार्क) के परिणाम अत्यधिक निर्भर करते हैं कि किस संचालन की तुलना की जाती है। उदाहरण के लिए, जावा 5.0 के साथ तुलना करते समय:
 * 32 और 64 बिट अंकगणितीय संचालन, इनपुट/आउटपुट|फ़ाइल I/O और अपवाद हैंडलिंग, तुलनीय C++ प्रोग्राम के समान प्रदर्शन है
 * ऐरे के संचालन का प्रदर्शन C में बेहतर है।
 * C में त्रिकोणमितीय फलनों का प्रदर्शन काफी बेहतर है।


 * टिप्पणियाँ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

यह भी देखें

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

बाहरी संबंध

 * Site dedicated to Java performance information
 * Debugging Java performance problems
 * Sun's Java performance portal
 * The Mind-map based on presentations of engineers in the SPb Oracle branch (as big PNG image)