क्या जावा वास्तव में धीमा है?


180

धीमी गति से चलने के लिए जावा में कुछ प्रतिष्ठा है

  • क्या जावा वास्तव में धीमा है?
  • यदि हाँ, तो क्यों? अड़चन कहां है (या थी)? क्या यह अक्षम जेवीएम के कारण है? कचरा इकठा करना? जेएनआई-लिपटे सी कोड के बजाय शुद्ध बायटेकोड लाइब्रेरी? कई अन्य भाषाओं में ये विशेषताएं हैं, लेकिन धीमेपन के लिए उनकी यह प्रतिष्ठा नहीं है।

35
लोग इतने घबरा जाते हैं ... देखते नहीं कि यह व्यक्तिपरक कैसे हो सकता है और न ही यह तर्कपूर्ण है। मुझे आश्चर्य है कि अगर "बबल सॉर्ट धीमा है" जैसा प्रश्न समान परिणाम प्राप्त करेगा। मैंने एक तकनीकी सवाल पूछा, और तकनीकी जवाब (जो मुझे मिला) चाहता था, लेकिन प्रश्न को व्यक्तिपरक और तर्क के रूप में बंद करना हास्यास्पद है।
स्टेफानो बोरीनी

1
मैंने अधिकांश शीर्ष टिप्पणियाँ पढ़ी हैं और उनमें से कोई भी इस तथ्य को स्पष्ट नहीं करता है कि C # GUI- आधारित डेस्कटॉप एप्लिकेशन आधुनिक जावा सहित किसी भी Java GUI- आधारित डेस्कटॉप एप्लिकेशन की तुलना में अधिक तेज़ चलते हैं।
बॉबटूरो

3
एक क्लाइंट-साइड वेब देव के रूप में, जिन्होंने .net webforms, .net MVC, PHP, रेल, Django और सब कुछ की एक विस्तृत विविधता के साथ निपटा है, लेकिन जावा में वसंत (जो मैंने सुना है अच्छा है), मुझे खराब प्रदर्शन / वास्तुकला की उम्मीद है जावा टीमों द्वारा निर्मित बैक एंड से। मुझे संदेह है कि वास्तविक समस्या बेंचमार्क नहीं है, बल्कि वहां का मुद्दा बस औसत दर्जे का जावा के क्रैप-टन होने के कारण वहां से हट जाता है। यह भाषा की गलती नहीं है। यह जावा देवों की गलती नहीं है, जो वास्तव में अपने शिल्प को बेहतर बनाते हैं और जावा के अलावा अन्य भाषाओं को सीखते हैं। हालाँकि, यह सामान्य रूप से सूर्य,, 90 के दशक, और आईटी उद्योग का दोष हो सकता है।
एरिक रेपेने

जवाबों:


236

आधुनिक जावा सबसे तेज़ भाषाओं में से एक है, भले ही यह अभी भी एक मेमोरी हॉग है। जावा की धीमी गति के लिए एक प्रतिष्ठा थी क्योंकि यह वीएम को शुरू करने के लिए एक लंबा समय लेता था।

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

अब "धीमी" जावा अनुप्रयोगों के लिए कोई बहाना नहीं है। डेवलपर्स और विरासत कोड / पुस्तकालयों को दोष देना है, भाषा की तुलना में कहीं अधिक। इसके अलावा, कुछ भी 'उद्यम को दोष दें।'

"जावा धीमा है" भीड़ के लिए निष्पक्षता में, यहां ऐसे क्षेत्र हैं जहां यह अभी भी धीमा है (2013 के लिए अद्यतन):

  • पुस्तकालय अक्सर "शुद्धता" और पठनीयता के लिए लिखे जाते हैं, प्रदर्शन नहीं। मेरी राय में, यह मुख्य कारण है जावा में अभी भी एक खराब प्रतिष्ठा है, विशेष रूप से सर्वर-साइड। यह स्ट्रिंग समस्याओं को तेजी से बदतर बना देता है। कुछ साधारण गलतियाँ आम हैं: प्रायः वस्तुओं का उपयोग आदिम के स्थान पर किया जाता है, प्रदर्शन को कम करने और स्मृति उपयोग को बढ़ाने के लिए। कई जावा पुस्तकालयों (मानक वाले सहित) परस्पर या सरल स्वरूपों (चार [] या स्ट्रिंगबफ़र) का पुन: उपयोग करने के बजाय अक्सर स्ट्रिंग्स बनाएंगे। यह धीमा है और बाद में इकट्ठा करने के लिए टन कचरा बनाता है। इसे ठीक करने के लिए, मेरा सुझाव है कि डेवलपर्स जहां संभव हो, आदिम संग्रह और विशेष रूप से जेवल्यूशन के पुस्तकालयों का उपयोग करें।

  • स्ट्रिंग ऑपरेशन थोड़ा धीमा है। जावा अपरिवर्तनीय, UTF-16- string स्ट्रिंग ऑब्जेक्ट्स का उपयोग करता है । इसका मतलब है कि आपको एएससीआईआई (सी, सी ++) की तुलना में अधिक मेमोरी, अधिक मेमोरी एक्सेस और कुछ ऑपरेशन की आवश्यकता है। उस समय, यह पोर्टेबिलिटी के लिए सही निर्णय था , लेकिन यह एक छोटी प्रदर्शन लागत वहन करता है। UTF-8 अब एक बेहतर विकल्प की तरह दिखता है।

  • सीमाओं की जाँच के कारण , C की तुलना में ऐरे एक्सेस थोड़ा धीमा है । जुर्माना बड़ा हुआ करता था, लेकिन अब छोटा है (जावा 7 बहुत हद तक निरर्थक सीमा की जाँच का अनुकूलन करता है)।

  • मनमाना मेमोरी एक्सेस का अभाव कुछ I / O और बिट-लेवल प्रोसेसिंग को धीमा कर सकता है (उदाहरण के लिए संपीड़न / अपघटन)। यह अब अधिकांश उच्च-स्तरीय भाषाओं की सुरक्षा विशेषता है।

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

  • धारा-आधारित I / O प्रत्येक स्ट्रीम एक्सेस पर सिंक्रनाइज़ेशन की आवश्यकता के कारण (IMO, खराब पसंद) के कारण धीमा हैNIO ने इसे ठीक कर दिया, लेकिन यह उपयोग करने के लिए एक दर्द है। एक समय में एक तत्व के बजाय एक सरणी में पढ़ने / लिखने के द्वारा इसके चारों ओर काम कर सकते हैं।

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

  • जावा अनुप्रयोगों को बहुत पुराने JVM संस्करणों से जोड़कर देखा जाना आम है। खासकर सर्वर-साइड। ये पुराने JVM नवीनतम संस्करणों की तुलना में अविश्वसनीय रूप से अक्षम हो सकते हैं।

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


हालाँकि, ऐसी कई जगहें हैं जहाँ जावा अन्य भाषाओं की तुलना में तेज़ है:

  • मेमोरी आवंटन और डी-आवंटन तेज और सस्ते हैं। मैंने ऐसे मामलों को देखा है, जहां एक कैश्ड के पुन: उपयोग की तुलना में एक नया, बहु-केबी सरणी आवंटित करने के लिए यह 20% FASTER (या अधिक!) है।

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

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

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

  • स्ट्रिंग्स में लंबाई शामिल होती है: कुछ ऑपरेशन तेज होते हैं। यह नल-सीमांकित स्ट्रिंग्स (सी में आम) का उपयोग करके धड़कता है। जावा 7 में, ओरेकल ने String.subString () ऑप्टिमाइज़ेशन को निकाल लिया, क्योंकि लोग इसे बेवकूफी से इस्तेमाल कर रहे थे और मेमोरी लीक हो रहे थे।

  • Array copy अत्यधिक अनुकूलित है। नवीनतम संस्करणों में, जावा System.arraycopy के लिए हाथ से ट्यून किए गए कोडांतरक का उपयोग करता है। इसका परिणाम यह है कि अरैस्कोपी / मेमकोपी-हेवी ऑपरेशंस में, मैंने देखा है कि मेरा कोड सी में समतुल्य को उचित मार्जिन से हरा रहा है।

  • J1 कंपाइलर L1 / L2 कैश का उपयोग करने के बारे में स्मार्ट है । समय-समय पर संकलित कार्यक्रम वास्तविक समय में अपने कोड को उस विशिष्ट सीपीयू और सिस्टम पर ट्विक नहीं कर सकते, जिस पर वे चल रहे हैं। जेआईटी इस तरह से कुछ बहुत ही कुशल लूप परिवर्तन प्रदान करता है।

कुछ अन्य ऐतिहासिक तथ्यों ने "जावा धीमी है" प्रतिष्ठा में योगदान दिया:

  • जेआईटी संकलन (जावा 1.2 / 1.3) से पहले, भाषा केवल व्याख्या की गई थी, संकलित नहीं की गई थी, और इस तरह बहुत धीमी गति से।
  • JIT संकलन को प्रभावी होने में समय लगा (प्रत्येक संस्करण के साथ प्रमुख सुधार)
  • पिछले कुछ वर्षों में क्लास लोडिंग बहुत अधिक कुशल हो गई है। स्टार्टअप के दौरान यह काफी अक्षम और धीमा हुआ करता था।
  • स्विंग और यूआई कोड ने देशी ग्राफिक्स हार्डवेयर का बहुत अच्छा उपयोग नहीं किया।
  • स्विंग सिर्फ भयानक है। मैं एडब्ल्यूटी और स्विंग को दोष देता हूं कि जावा डेस्कटॉप के लिए कभी क्यों नहीं पकड़ा गया।
  • पुस्तकालय कक्षाओं में सिंक्रनाइज़ेशन का भारी उपयोग; अब असंबद्ध संस्करण उपलब्ध हैं
  • नेटवर्क पर एक पूर्ण JAR प्रसारित करने और VM को बूट करने के लिए लोड करने के कारण Applets हमेशा लोड करने के लिए ले जाता है ।
  • सिंक्रोनाइज़ेशन का उपयोग एक भारी प्रदर्शन दंड के लिए किया जाता है (इसे प्रत्येक जावा संस्करण के साथ अनुकूलित किया गया है)। प्रतिबिंब अभी भी महंगा है, हालांकि।

49
Object instantiation and object-oriented features are blazing fast to use (faster than C++ in many cases) because they're designed in from the beginning.और Collections are fast. Standard Java beats standard C/C++ in this area, even for most optimized C code.यहां से जुड़े किसी भी साक्ष्य द्वारा असमर्थित जंगली दावे हैं।
मोजरद

8
@Sjoerd - दावे शायद ही जंगली हैं - वे मेरे लिए स्पष्ट हैं, और किसी को भी होना चाहिए जो सी / सी ++ बनाम जावा में डिफ़ॉल्ट मेमोरी सिस्टम की वास्तुकला में अंतर को समझता है। आप कर सकते हैं ज्यादा बेहतर अभी भी अगर आप अपने खुद के स्मृति संचालकों (मुक्त सूचियों, स्मृति पूल, और इतने पर की तरह चीजों के साथ) लिख सकता हूं या औजार ऐसी है कि एक पुस्तकालय का उपयोग करें।
रेक्स केर

15
@ Rex Kerr - यदि आप आवंटन के लिए ढेर का उपयोग कर सकते हैं तो मेमोरी हैंडलर का उपयोग क्यों करें ?! आप ऑब्जेक्ट तात्कालिकता के साथ हीप मेमोरी आवंटन को भ्रमित कर रहे हैं।
Sjoerd

20
@Rex Kerr - मूल रूप से आप दावा कर रहे हैं कि क्योंकि जावा में सब कुछ में ढेर पर मेमोरी आवंटित करना शामिल है, और क्योंकि जावा में हीप पर जावा का आवंटन C ++ की तुलना में तेज है, जावा में सब कुछ तेज है। यहां आपके लिए कुछ समाचार हैं: सी ++ में आप कई मामलों में ढेर पर मेमोरी को आवंटित किए बिना कर सकते हैं!
सोजेरड

10
@Sjoerd - मैंने कहां कहा कि जावा में सब कुछ तेज है? मैंने जो कहा, उसे बस पढ़ें। मैंने कहा कि मेरा क्या मतलब है, और आपने अपनी पिछली टिप्पणी में जो कुछ भी कहा है उसे पहले ही संबोधित कर चुके हैं।
रेक्स केर

49

प्रारंभ में जावा विशेष रूप से तेज़ नहीं था, लेकिन यह अधिक धीमा भी नहीं है। इन दिनों, जावा बहुत तेज है। जिन लोगों से मैंने जावा के धीमे होने की बात की है, वे दो चीजों से आते हैं:

  1. वीएम स्टार्टअप समय धीमा करें। प्रारंभिक जावा कार्यान्वयन को शुरू करने और देशी अनुप्रयोगों की तुलना में आवश्यक पुस्तकालयों और आवेदन को लोड करने में लंबा समय लगा।

  2. धीरे यूआई। अर्ली स्विंग धीमी थी। यह संभवतः मदद नहीं करता था कि अधिकांश विंडोज उपयोगकर्ताओं ने डिफ़ॉल्ट धातु एल एंड एफ बदसूरत पाया।

उपरोक्त बिंदुओं को देखते हुए, यह कोई आश्चर्य नहीं है कि लोगों को 'जावा धीमा है' छाप मिला।

उन उपयोगकर्ताओं या डेवलपर्स के लिए जो मूल एप्लिकेशन, या यहां तक ​​कि विज़ुअल बेसिक एप्लिकेशन विकसित करने के लिए उपयोग किए जाते हैं, ये दो बिंदु एक आवेदन में सबसे अधिक दिखाई देने वाली चीज है, और यह पहली छाप है जो आपको एक आवेदन के बारे में मिलेगी (जब तक कि यह एक गैर-जीयूआई आवेदन न हो जिसमें मामला केवल 1. लागू होता है।)।

आप किसी उपयोगकर्ता को यह विश्वास नहीं दिलाएंगे कि "यह कोड बहुत तेज़ी से कोड निष्पादित करता है" जब आवेदन शुरू होने में 8 सेकंड लगते हैं बनाम उसका पुराना विज़ुअल बेसिक एप्लिकेशन जो तुरंत शुरू होता है - भले ही कोड निष्पादन और स्टार्टअप समय बिल्कुल भी जुड़ा नहीं हो।

पहली छाप को बर्बाद करना अफवाहों और मिथकों को शुरू करने का एक शानदार तरीका है। और अफवाहों और मिथकों को मारना कठिन है।

संक्षेप में, जावा धीमा नहीं है। "जावा धीमा रवैया" वाले लोग 10 साल पहले जावा के पहले छापों पर आधारित हैं।


3
कुछ साल पहले जावा बहुत धीमा था, लेकिन हाल के बेंचमार्क परीक्षणों में यह लगभग C / C ++ जितना तेज़ चलता है और कुछ स्थितियों में यह तेजी से चलता है।
चाडएनसी

23
मेरे मैकबुक पर OSX 10.6 पर जावा ऐप्स, उद्देश्य-सी में लिखे गए ऐप की तुलना में बहुत धीमा है। त्वरित स्टार्टअप समय के लिए क्या सबूत है?
ज़ेन लिंक्स

2
Decompression बिल्कुल एक प्रदर्शन समस्या नहीं है। 1992 में मेरा कंप्यूटर उन प्रोग्रामों को शुरू करने के लिए निष्कासित कर देता है, जो हार्ड ड्राइव से लंबी फ़ाइल लोड करने पर प्रदर्शन में सुधार करते हैं। सीपीयू और हार्ड ड्राइव के बीच असमानता बीच के वर्षों में काफी बढ़ गई है। हालाँकि, rt.jar के लिए ज़िप संग्रह प्रारूप का उपयोग करने में समस्या है (क्यों? !!!) और निहित वर्ग फाइलें लिंक नहीं हैं (नट ..)।
टॉम हॉल्टिन -

5
@Zan: ध्यान दें कि Apple द्वारा Mac OS X के लिए JVM (या कम से कम अनुकूलित) लिखा गया है। जिन प्लेटफार्मों का वे समर्थन करते हैं (विंडोज़, लिनक्स और सोलारिस) पर स्टार्टअप समय को तेज करने के लिए सन ने काफी समय निवेश किया है, लेकिन वे इसे मैक ओएस एक्स के लिए नहीं कर सकते (क्योंकि वे उस पोर्ट को बनाए नहीं रखते हैं)। यह हो सकता है कि मैक मैक ओएस एक्स पर उन सभी अनुकूलन के लिए मैक को लागू नहीं कर सकता / पोर्ट नहीं कर सकता था।
जोकिम सॉयर

1
मैं जावा को धीमा नहीं मानता (मैं गेम बनाने वाले को जानता हूं जो उनमें गेम बनाता है); यूआई कारणों से सिर्फ बुरा। एक भी "नियमित" जावा ऐप मैंने नहीं देखा है एक सभ्य, पूरी तरह से काम कर रहे यूआई।
RCIX

40

टिप्पणियों से भरे एक पृष्ठ को पढ़ने के बाद यह कहना कि जावा धीमा नहीं है, मुझे बस एक अलग राय के साथ जवाब देना है।

किसी भाषा की सुस्ती बहुत कुछ इस बात पर निर्भर करती है कि आपकी अपेक्षाएँ 'तेज़' के लिए क्या हैं। यदि आप C # तेज़ मानते हैं, तो जावा निश्चित रूप से तेज़ है। यदि आपकी समस्या डोमेन डेटाबेस से संबंधित है, या अर्ध-वास्तविक समय प्रसंस्करण है, तो निश्चित रूप से जावा काफी तेज है। यदि आप अधिक हार्डवेयर जोड़कर अपने एप्लिकेशन को स्केल करने में खुश हैं, तो जावा आपके लिए तेजी से संभव है। यदि आप समझते हैं कि 5-10 के पैमाने में एक स्थिर कारक स्पीडअप इसके लायक नहीं है, तो आप संभवतः जावा फास्ट मानते हैं।

यदि आप बड़े डेटा सेटों पर संख्यात्मक गणना करते हैं, या निष्पादन पर्यावरण के लिए बाध्य हैं, जहां सीपीयू संसाधन सीमित हैं, जहां 5-10 के पैमाने में एक निरंतर गति बहुत बड़ी होगी। यहां तक ​​कि 0.5 स्पीड अप का मतलब गणना पूरी होने के लिए 500 घंटे की कटौती हो सकती है। इन मामलों में, Java आपको प्रदर्शन के उस अंतिम यार्ड को प्राप्त करने की अनुमति नहीं देता है, और आप संभवतः जावा को धीमा मानते हैं।


2
पूरी पोस्ट पर सहमत, और +1 क्योंकि आप एक मान्य बिंदु प्रस्तुत करते हैं, हालांकि, उदाहरण के लिए C ++ में डिबग करने में मुश्किल होने की अलग प्रसिद्धि है, और अपने पूरे पैर को उड़ाने के लिए आसान है, लेकिन शायद ही मैंने C ++ के बारे में सुना है जितना धीमा है। जैसा कि मैंने जावा के बारे में सुना है।
स्टेफानो बोरीनी

33

आप दो अलग-अलग प्रश्न पूछ रहे हैं:

  1. क्या जावा वास्तव में धीमा है, और यदि ऐसा है तो क्यों?
  2. जावा को धीमा क्यों माना जाता है, भले ही यह कई विकल्पों से तेज हो?

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

यह बहुत कुछ मुख्य रूप से कार्यान्वयन से संबंधित है - मूल रूप से, यह इस तथ्य से नीचे आता है कि एक उपयोगकर्ता प्रतीक्षा कर रहा है जबकि एक गतिशील / जेआईटी कंपाइलर चलता है, इसलिए जब तक आपके पास एक प्रोग्राम नहीं है जो शुरू करने के लिए काफी समय तक चलता है, यह कंपाइलर का औचित्य साबित करना कठिन अनुकूलन पर बहुत समय बिताता है। इसलिए, अधिकांश जावा (और सी #, आदि) संकलक वास्तव में कठिन अनुकूलन में बहुत प्रयास नहीं करते हैं। बहुत सारे मामलों में, यह अनुकूलन के बारे में कम है कि वे कहाँ लागू होते हैं। कई अनुकूलन समस्याएं एनपी पूरी होती हैं, इसलिए वे जिस समय लेते हैं समस्या के आकार के साथ तेज़ी से बढ़ते हैं। कारण के भीतर समय रखने का एक तरीका केवल यह है कि एक बार में एक ही फ़ंक्शन की तरह अनुकूलन को लागू करें। जब यह केवल डेवलपर के लिए इंतजार कर रहा है, आप बहुत अधिक समय ले सकते हैं, और कार्यक्रम के बहुत बड़े हिस्से में वही अनुकूलन लागू कर सकते हैं। इसी तरह, कुछ अनुकूलन के लिए कोड बहुत बालों वाला है (और इसलिए बहुत बड़ा हो सकता है)। फिर से, चूंकि उपयोगकर्ता प्रतीक्षा कर रहा है कि कोड लोड हो रहा है (और समग्र समय में JVM स्टार्टअप समय अक्सर एक महत्वपूर्ण कारक है), कार्यान्वयन को एक स्थान पर सहेजे गए समय को शेष बनाम दूसरे में खो दिया - और कितना कम कोड दिया जाता है बालों के अनुकूलन से लाभ, जेवीएम को छोटा रखना आमतौर पर अधिक फायदेमंद होता है।

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

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

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

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

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


16

यह जावा के शुरुआती दिनों (1990 के दशक के मध्य से) की आउट-डेटेड जानकारी है। जावा के हर प्रमुख संस्करण में पिछले संस्करण की तुलना में महत्वपूर्ण गति-अप पेश किए गए हैं। ओरेकल जाहिरा तौर पर जावा 7 के लिए सूर्य की JVM के साथ JRockit को मर्ज करने के साथ, इस प्रवृत्ति को जारी रखने के लिए तैयार है।

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


14

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

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

जावा में, हर बार लिंक करने के बाद एप्लिकेशन चलाया जाता है। इसलिए लंबा स्टार्टअप समय।

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

बाद में प्रदर्शन के लिए, सरणी एक्सेस (ज्यादातर हैश फ़ंक्शंस और अन्य क्रिप्टोग्राफ़िक एल्गोरिदम) के साथ कॉम्पैक्ट संगणना पर मेरे अपने बेंचमार्क आमतौर पर दिखाते हैं कि अनुकूलित सी कोड जावा कोड की तुलना में लगभग 3x तेज है; कभी-कभी C, जावा की तुलना में केवल 30% अधिक तेज होता है, कभी-कभी C कार्यान्वित एल्गोरिदम के आधार पर 4x तेज हो सकता है। मैंने एक 10x कारक देखा जब 64x64-> 128 गुणक opcodes के कारण "C" कोड वास्तव में बड़े पूर्णांक अंकगणित के लिए असेंबली था, जो प्रोसेसर प्रदान करता है, लेकिन जावा उपयोग नहीं कर सकता क्योंकि इसका सबसे लंबा पूर्णांक प्रकार 64-बिट है long। यह एज केस है। व्यावहारिक परिस्थितियों में, I / O और मेमोरी बैंडविड्थ विचार सी कोड को जावा की तुलना में वास्तव में तीन गुना तेज होने से रोकते हैं ।


हम्म ... मुझे लगा कि ज्यादातर सी लाइब्रेरी आजकल गतिशील रूप से जुड़ी हुई हैं। या आप कुछ अलग बोल रहे हैं?
सीन मैकमिलन

4
@ सीन: सी के लिए गतिशील लिंकिंग "बाहरी प्रतीकों" के लिए होता है: जो फ़ंक्शन एक DLL में उपयोग किए जाते हैं और दूसरे में परिभाषित होते हैं। एक विशिष्ट सी एप्लिकेशन एक दर्जन डीएलएल का उपयोग करेगा। जावा डायनेमिक लिंकिंग के लिए सभी वर्गों में सभी विधियों के लिए होता है: एक विशिष्ट जावा एप्लिकेशन (मानक पुस्तकालय सहित) में हजारों हैं । सी दुनिया में, अधिकांश लिंकिंग (सभी लिंक जो एक डीएलएल सीमा को पार नहीं करते हैं) को संकलन समय पर हल किया जाता है, केवल एक छोटा अनुपात अभी भी रनटाइम पर करना है।
थॉमस पोर्निन

14

जावा निश्चित रूप से धीमा है, खासकर मात्रात्मक काम के लिए।

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

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

मेरी मशीन 3 जीबी रैम के साथ एक एचपी कोर 2 डुओ है । मैं 64-बिट Ubuntu 10.04 (ल्यूसिड लिंक्स) का उपयोग करता हूं ।


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

7
जब आपने JNI के माध्यम से कॉल की गई लिब्रायर्स में गुणा किया तो जावा को कितना समय लगा। यह देखते हुए कि आप C / C ++ में कुछ भी कर सकते हैं, आप JNI के साथ कर सकते हैं (कुछ सौ mnano-seconds जोड़ें) मार्जिन अपेक्षाकृत छोटा है। मुझे लगता है कि आपके आर और पायथन मैट्रिक्स गुणन आर या पायथन में नहीं लिखा गया था, बस उन भाषाओं से कहा जाता है।
पीटर लॉरी

2
जिज्ञासा से बाहर, क्या आपने यह पहचानने के लिए कोई रूपरेखा तैयार की है कि क्या आपके कोड में कुछ हॉटस्पॉट है (प्रकार रूपांतरण / ऑटोबॉक्सीक्स)?
थोरबजोरन रावन एंडरसन

10

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

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

यह सब एक सर्वर पर जावा के प्रदर्शन, या कई अन्य तरीकों से जावा के प्रदर्शन से कोई लेना-देना नहीं है। लेकिन यह वही है जो लोग देखते हैं, और गैर-जावा डेवलपर्स को याद है जब वे जावा के बारे में सोचते हैं।


9

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

यदि आप यह देखना चाहते हैं कि JIT संकलन कितना बड़ा अंतर बनाता है, तो कंप्यूटर लैंग्वेज बेंचमार्क गेम में व्याख्या किए गए बनाम गैर-व्याख्या किए गए बेंचमार्क देखें । (Pidigits सभी संगणनाओं को करने के लिए एक बाहरी पुस्तकालय का उपयोग करता है, ताकि बेंचमार्क में बदलाव न हो; बाकी लोग 6-16x स्पीडअप दिखाते हैं!)

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


6

जावा WAS धीमा, दिन में वापस। प्रदर्शन में वृद्धि की कुछ पीढ़ियों के कारण यह बहुत तेज हो गया है । आखिरी बार मैंने सुना, यह आमतौर पर सी # गति के 10% के भीतर होता है - कभी तेज, कभी धीमा।

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

इसके अलावा, कम से कम कुछ लोग हैं जो जावा की व्यवहार्यता पर कभी विश्वास नहीं करेंगे।


1
दुर्भाग्य से JVM स्टार्टअप CLR स्टार्टअप की तुलना में बहुत धीमा है। इसका कारण यह है कि सूर्य ने जावा 7 को जारी करने में सबसे खराब तरीके से अपने पैर खींचे हैं, इसलिए हम वृद्धिशील पैच के साथ 4 साल पुराने जावा 6 से
फंस गए हैं।

3
वाह, जावा 6 4 साल पुराना है ??? हां मुझे लगता है (यदि आप बीटा की गिनती करते हैं)। अभी भी मेरे लिए नया लगता है - मैंने काम पर केवल 1.4 का उपयोग करना बंद कर दिया।
कलेब ब्रासी

जावा १.४ प्रयोग करने योग्य है, लेकिन एक प्रकार का चूना, १.५ और १.६ के बाद से बहुत सारे प्रदर्शन बूस्ट और सिंटैक्टिक चीनी मिलाए गए। तब से सीमा-जाँच और System.arraycopy अनुकूलन शुरू किए गए थे। इसलिए बहुत सारे सिंक्रोनाइज़ेशन सुधार हुए। मुझे लगता है कि 1.4 सही मायने में यह कहना उचित है।
BobMcGee

LOL, मुझे पता है - हर बार जब मुझे मैन्युअल रूप से पुनरावृत्त करना होता है या एक सामान्य सूची के बजाय एक सरणी का उपयोग करना होता है, तो मैं अपने लैपटॉप को आधे में तोड़ना चाहता हूं ... आईबीएम के पास वास्तव में जावा 5 वर्ष के लिए WAS 6.1 पर उपलब्ध है, लेकिन मैं ' वीएएस 6.0 पर अटक गया है :( मैं जावा 5/6 का उपयोग कर रहा हूं क्योंकि यह मेरे अपने सामान के लिए निकला है, लेकिन मैं काम पर पुराने सर्वर संस्करणों द्वारा सीमित हूं। 1.4 से नवीनतम संस्करणों में दोहरे अंकों का प्रदर्शन सुधार है। बहुत कुछ के लिए, और मैं आगे उन्हें देख रहा हूँ।
Kaleb Brasee

6

Stefano:

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

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

बैकएंड और कम्प्यूटेशनल स्तर पर जावा इतना धीमा नहीं है। बछेड़ा सबसे अच्छे उदाहरणों में से एक है:

नवीनतम स्थिर Colt रिलीज़ JDK ibm-1.4.1, RedHat 9.0, 2x IntelXeon@2.8 GHz पर 1.9 Gflop / s बैरियर को तोड़ती है।

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

मुझे लगता है कि आम तौर पर आज यह एक राजनीतिक निर्णय है (जैसे आईफोन / आईपॉड पर कोई जावा समर्थन नहीं), और जावा के खिलाफ एक भाषा के रूप में एक निर्णय (क्योंकि कई लोग सोचते हैं कि यह बहुत वाचाल है)।

हालाँकि, आजकल जावा वीएम के लिए कई अन्य भाषाएँ हैं (जैसे कि पायथन, रूबी, जावास्क्रिप्ट, ग्रूवी, स्काला आदि) जो एक विकल्प हो सकती हैं।

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


ठीक है, तो एक और खराब प्रतिष्ठा जीयूआई टूलकिट से आई है। बेशक, मुझे लगता है कि, आधुनिक जेवीएम देशी विजेट का उपयोग करते हैं, वे ओएस पुस्तकालयों में हुक करते हैं, है ना? या वे होस्ट प्लेटफॉर्म के एक ही रूप और अनुभव को प्रस्तुत करने के लिए AWT / स्विंग का उपयोग करते हैं?
स्टेफानो बोरीनी

स्टीफनो: स्विंग वास्तव में विगेट्स के गैर-देशी सार्वभौमिक प्रतिपादन के विचार पर आधारित है, इसलिए आपकी धारणा गलत है। यह वास्तव में एक "प्लगेबल लुक एंड फील" तंत्र है जो स्विंग घटकों को देशी घटकों की उपस्थिति का अनुकरण करने की अनुमति देता है। यदि आप ऐसा कुछ खोज रहे हैं, तो आप SWT ( eclipse.org/swt ) की जांच कर सकते हैं , जो वास्तव में देशी OS में हुक करेगा और JNI (जिसे अड़चन कहा जाता है) का उपयोग करके देशी विजेट का उपयोग करेगा।
डाइटर

Java2D (स्विंग के लिए उपयोग किया जाता है) इन दिनों बहुत जल्दी है, और देशी विजेट (SWT) का उपयोग करने से कोई प्रदर्शन लाभ नहीं मिलता है। कम से कम, यह वही है जो मैंने तब पढ़ा जब मैं 6 महीने पहले स्विंग या एसडब्ल्यूटी सीखना सीख रहा था।
लुइगी प्लिंज

4

एक हथौड़ा कई अन्य उपकरणों की तुलना में आटा बाहर रोल करने में बहुत धीमा है। हथौड़ा को "धीमा" नहीं बनाता है, और न ही उन कार्यों के लिए कम उपयोगी है जो इसे करने के लिए डिज़ाइन किया गया है।

एक सामान्य प्रोग्रामिंग भाषा के रूप में, जावा प्रोग्रामिंग कार्यों की एक विस्तृत श्रृंखला के लिए कई (यदि नहीं) के बराबर है। विशिष्ट, तुच्छ परीक्षण हैं, जिनके लिए जावा कम परिष्कृत भाषाओं में हाथ-कोड किए गए समाधानों को बेहतर नहीं करेगा, जो "धातु के करीब" हैं।

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


3

जावा एक उच्च-स्तरीय भाषा है और इसकी प्रतिष्ठा आजकल अन्य, तुलनीय उच्च-स्तरीय भाषाओं के साथ प्रदर्शन करने की है।

  1. इसमें डायनामिक बाइंडिंग शब्दार्थ है। C ++ की तुलना में जहां गैर-आभासी तरीकों को फ़ंक्शन कॉल के रूप में संकलित किया जाता है, यहां तक ​​कि दुनिया के सबसे अच्छे जावा कंपाइलर को कोड का उत्पादन करना पड़ता है जो कम कुशल है। लेकिन यह एक क्लीनर, अधिक उच्च-स्तरीय शब्दार्थ भी है।

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

  3. एक अन्य तरीका जिसमें जावा एक उच्च-स्तरीय भाषा है, जिसमें कचरा-संग्रह है । कचरा-संग्रह की तुलना में धीमी हो सकती है mallocऔर freeकार्यक्रमों है कि एक बार सभी स्मृति वे की जरूरत है और उस के साथ काम पर आवंटित करने के लिए। समस्या यह है कि जिन भाषाओं में कचरा-संग्रह नहीं होता है, प्रोग्रामर केवल उन कार्यक्रमों को लिखते हैं जो एक बार में आवश्यक सभी मेमोरी को आवंटित करते हैं और असफल हो जाते हैं यदि यह कुछ मनमाना अधिकतम आकार स्थिर हो जाता है। तो तुलना संतरे के लिए सेब है। जब प्रोग्रामर गैर-जीसी भाषाओं में जंजीर संरचनाओं के गतिशील आवंटन के साथ कार्यक्रमों को लिखने और डिबग करने का प्रयास करते हैं, तो वे कभी-कभी पाते हैं कि उनके कार्यक्रम अब जीसी भाषा की तुलना में तेज नहीं हैं, क्योंकि mallocऔरfreeस्वतंत्र नहीं हैं! उनके पास ओवरहेड भी है ... इसके अलावा, जीसी बलों के पास यह निर्दिष्ट करने के लिए नहीं है कि कौन क्या मुक्त करता है, और यह निर्दिष्ट करने के लिए कि कौन मुक्त करता है जो बदले में आपको प्रतियां बनाने के लिए मजबूर करता है - जब कई कार्यों के लिए डेटा की आवश्यकता होती है और यह स्पष्ट नहीं है कि कौन अंतिम बार इसका उपयोग किया जाएगा - जबकि जीसी भाषा में कॉपी करना आवश्यक नहीं होगा।


1. शायद हॉटस्पॉट के साथ सच नहीं है। 2. केवल यदि आप विधि को सिंक्रनाइज़ के रूप में चिह्नित करते हैं।
विंस्टन एवर्ट

1
1. कंपाइलर कोड का अनुकूलन नहीं करता है, लेकिन जेवीएम केवल एक या दो आभासी तरीकों को गतिशील रूप से निर्धारित करने के लिए पर्याप्त रूप से स्मार्ट है और आमतौर पर उन्हें स्थैतिक रूप से कॉल कर सकते हैं या उन्हें इनलाइन भी कर सकते हैं। मुझे पूरा यकीन है कि C ++ वर्चुअल मेथड को इनलाइन नहीं कर सकता है। 2. हर जावा ऑब्जेक्ट में एक लॉक होता है। इसका प्रत्येक ऑब्जेक्ट पर एक छोटा ओवरहेड (एक बाइट के बारे में) होता है, लेकिन उपयोग न होने पर बहुत कम प्रभाव पड़ता है। 3. जावा में आप एक बार में अपनी जरूरत की सभी वस्तुओं को आवंटित कर सकते हैं। यह आपको आवेदन कर सकता है जो पूरे दिन जीसी नहीं करता है। ;) जावा के जीसी को स्पष्ट रूप से बहु-थ्रेडेड किया जाता है, कुछ ऐसी चीज़ों की आवश्यकता होती है जिन्हें C ++ में विशेष लीब्रा की आवश्यकता होती है।
पीटर लॉरी

C ++ वर्चुअल कॉल्स को इनलाइन कर सकता है, लेकिन जावा इसे और अधिक मामलों में कर सकता है, और यह मेगामॉर्फिक कॉल साइट्स को अनुकूलित करने के साथ मजबूत भी है।
पायोत्र कोआलाज़कोव्स्की

2

नब्बे के दशक के मध्य में जब जावा ने मुख्यधारा को मारा, सी ++ प्रमुख भाषा थी, और वेब अभी भी काफी नया था। इसके अलावा, जेवीएम और जीसी मुख्यधारा के विकास में अपेक्षाकृत नई अवधारणाएं थीं। शुरुआती JVM धीमी तरह के थे (नंगे धातु पर चलने वाले C ++ की तुलना में) और कभी-कभी लंबे कचरा संग्रहण ठहराव से भी ग्रस्त थे, जिससे जावा की प्रतिष्ठा धीमी हो गई थी।


क्या यह जीसी के पीछे की तकनीक के कारण था? मुझे पता है कि उनके पास जीसी चरण में अधिक कुशल होने के लिए कुछ रणनीतियाँ (जैसे वस्तुओं के लिए जेनेरिक परतें) हैं। उस समय क्या रणनीति थी?
स्टेफानो बोरीनी

1
आईएएनए जेवीएम विशेषज्ञ, लेकिन मुझे लगता है कि उस समय जीसी के लिए एक एकल थ्रेडेड मार्क / स्वीप एल्गोरिथ्म का उपयोग किया गया था, जिसे जीसी प्रदर्शन किए जाने के दौरान पूरे जेवीएम को थामने की आवश्यकता थी। आजकल समवर्ती मार्क / स्वीप है और जेवीएम में कई अन्य प्रदर्शन में वृद्धि भी है।
केन लियू

2
आधुनिक जीसी एल्गोरिदम अच्छे हैं लेकिन मुझे लगता है कि सबसे बड़ा सुधार जेआईटी था।
पास्कल थिवेंट

1

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

कई (अधिकांश) लोग सामान्यीकरण करना पसंद करते हैं, इसलिए वे कहते हैं कि "जावा धीमा है" क्योंकि उन्हें लगता है कि जब वे उनके साथ बातचीत करते हैं तो ऐप धीमा होते हैं।


क्या आपको लगता है कि उच्च मेमोरी खपत उपकरण से या जावा पुस्तकालयों से आती है?
स्टेफानो बोरीनी

ग्रहण के मामले में - ग्रहण के बुनियादी ढांचे से ही। अतीत में "भारी" GUIs के लिए समान (JBuilder जैसा कि मुझे याद है)। मुझे इस बात का अहसास है कि यह इसलिए है क्योंकि बहुत से बॉयलरप्लेट ऑब्जेक्ट को एक स्टेटिक रूप से टाइप की गई भाषा में प्लगइन आर्किटेक्चर (जैसे एक्लिप्स) का उपयोग करने की आवश्यकता होती है। Emacs में प्लगइन्स भी हैं और इसकी मेमोरी की खपत ठेठ कोडिंग करते समय ग्रहण से 10-20x कम है। Emacs Lisp कोड को bytecode द्वारा संकलित किया गया है और emacs के उदाहरण में लोड किया गया है, फिर जावा क्लास लोडर के समान चलाया जाता है। मुझे लगता है कि जावा में कुछ अस्थिरता की अनुमति देने के लिए मध्यवर्ती वस्तुओं के टन हैं।
वोज्शिएक काज़मारेक

1

जावा अनुप्रयोगों के साथ बड़ी समस्या यह है कि यह स्टॉक रनटाइम लाइब्रेरी के बड़े आकार के कारण बहुत बड़ा है । विशाल कार्यक्रम स्मृति में बहुत कुछ भरते हैं और स्वैप करते हैं, जिसका अर्थ है कि वे धीमे हो जाते हैं।

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

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


1

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

असल में, यह बहुत कम या कोई अनुकूलन के साथ सॉफ्टवेयर एमुलेशन था जिसे हम आज जेवीएम में प्रदान करते हैं।


0

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

या शायद "लोग बेवकूफ हैं" एक बेहतर जवाब है।


0

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


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

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

आप मतलब है, हॉटस्पॉट अनुकूली अनुकूलन की तरह कुछ?
स्टेफानो बोरीनी

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

1
JIT संकलन का समय सर्वर जैसे लंबे समय तक चलने वाले ऐप्स के लिए नगण्य है। पीजीओ के साथ एओटी कम से कम 2 कारणों से जेआईटी की तुलना में अधिक सीमित है। सबसे पहले, अधिकांश प्रदर्शन अंतर हल्के अनुकूलन द्वारा प्राप्त किया जाता है। Gcc -O2 की तुलना gcc -O3 से करें। ज्यादातर समय कोई अंतर नहीं होता है , कभी-कभी -3 थोड़ा बेहतर हो सकता है, कभी-कभी थोड़ा बदतर हो सकता है, लेकिन मैंने कभी भी इससे कोई 2x अंतर का अनुभव नहीं किया है। दूसरा, पीजीओ के साथ भी एओटी का उपयोग करके आप केवल अनुमान लगा सकते हैं कि उपयोग-स्थल पर प्रोफ़ाइल क्या होगी। गलत लगता है, और आप JIT से बहुत पीछे हैं। और वास्तविक प्रोफ़ाइल बेहद कॉन्फ़िगर-निर्भर हो सकती है।
पिओट्र कोआलाज़कोव्स्की
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.