स्केला बनाम जावा, प्रदर्शन और स्मृति? [बन्द है]

Question

मैं स्काला को देखने के लिए उत्सुक हूं, और एक मूल प्रश्न है कि मुझे इसका जवाब नहीं मिल रहा है: सामान्य तौर पर, क्या स्काला और जावा के बीच मेमोरी के प्रदर्शन और उपयोग में अंतर है?

Comments

मैंने सुना है कि प्रदर्शन बहुत करीब हो सकते हैं। मुझे संदेह है कि यह इस बात पर अत्यधिक निर्भर है कि आप क्या कर रहे हैं। (यह जावा बनाम सी के लिए है के रूप में)

— पीटर Lawrey

इस प्रकार के प्रश्नों का उत्तर "यह निर्भर करता है" - सिस्टम X बनाम सिस्टम Y. प्लस की किसी भी तुलना के लिए, यह stackoverflow.com/questions/2479819/…

— जेम्स मूर

Answer 1

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

int n = 0;
for (String s: array) {
  if (s.length > 2 && mapping.containsKey(s)) n++;
}
String[] bigEnough = new String[n];
n = 0;
for (String s: array) {
  if (s.length <= 2) continue;
  bigEnough[n++] = map.get(s);
}

वाह! कठोर परिश्रम। स्काला में, समान कार्य करने का सबसे कॉम्पैक्ट तरीका है:

val bigEnough = array.filter(_.length > 2).flatMap(mapping.get)

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

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

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

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

Comments

उस अंतिम पैराग्राफ के लिए +1। यह एक महत्वपूर्ण बिंदु है जो बहुत दूर विचार से बाहर है ।

— केविन राइट

मुझे लगा कि आपके द्वारा बताए गए मुद्दों के साथ विचार बहुत मदद कर सकते हैं। या सरणियों के साथ सच नहीं है, विशेष रूप से?

— निकोलस पैलेट

@ केविन राइट - "यह एक महत्वपूर्ण बिंदु है जो बहुत दूर विचार से बाहर है" - यह ऐसा कुछ है जो कहना आसान है और प्रदर्शित करना मुश्किल है, और रेक्स केर के कौशल के बारे में हमें कुछ बताएं जो दूसरों को कम कुशल हासिल नहीं करता है।

— .गौई

>> शानदार प्रदर्शन के साथ मुहावरेदार शैली में << मुहावरेदार स्काला कार्यक्रमों के लिए बेंचमार्क गेम में कमरा है जो "शानदार" प्रदर्शन को प्राप्त नहीं करता है।

— इगौई

@RexKerr - क्या आपका जावा उदाहरण प्रत्येक संभव स्ट्रिंग के लिए दो बार मैपिंग कुंजी की खोज नहीं करता है, जहाँ आपका स्केल उदाहरण स्ट्रिंग्स के चयन के बाद केवल एक बार होता है? यानी वे अलग-अलग डेटा सेट के लिए अलग-अलग तरीकों से अनुकूलित हैं?

— सेठ

Answer 2

मैं एक नया उपयोगकर्ता हूँ, इसलिए मैं ऊपर रेक्स केर के जवाब के लिए एक टिप्पणी जोड़ने में सक्षम नहीं कर रहा हूँ ( "जवाब" करने के लिए नए उपयोगकर्ताओं को अनुमति देने के लिए नहीं, बल्कि "टिप्पणी" एक बहुत ही अजीब नियम btw है)।

मैंने साइन अप करने के लिए बस जवाब दिया "phew, Java is verbose and such hard work" insinuation of Rex's popular s। जब आप निश्चित रूप से अधिक संक्षिप्त स्काला कोड लिख सकते हैं, तो दिए गए जावा उदाहरण स्पष्ट रूप से फूला हुआ है। अधिकांश जावा डेवलपर्स कुछ इस तरह से कोड करेंगे:

List<String> bigEnough = new ArrayList<String>();
for(String s : array) {
  if(s.length() > 2 && mapping.get(s) != null) {
    bigEnough.add(mapping.get(s));
  }
}

और हां, अगर हम यह ढोंग करने जा रहे हैं कि एक्लिप्स आपके लिए अधिकांश वास्तविक टाइपिंग नहीं करता है और यह कि हर चरित्र वास्तव में आपको बेहतर प्रोग्रामर बनाता है, तो आप इसे कोड कर सकते हैं:

List b=new ArrayList();
for(String s:array)
  if(s.length()>2 && mapping.get(s) != null) b.add(mapping.get(s));

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

Comments

आप कैसे "महीने की हिप भाषा" क्लब के सदस्य नहीं हैं? अच्छी टिप्पणियाँ। मुझे विशेष रूप से अंतिम पैराग्राफ पढ़ने में बहुत मजा आया।

— स्टीफन

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

— chrisjleu

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

— आशालैंड

जब हम उस पर, java8 में यह होगा:Arrays.stream(array).map(mapping::get).filter(x->x!=null).toArray(File[]::new);

— bennyl

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

— योशिय्याह

Answer 3

अपने स्कैला को जावा की तरह लिखें, और आप लगभग समान बाइटकोड से उत्सर्जित होने की उम्मीद कर सकते हैं - लगभग समान मैट्रिक्स के साथ।

अपरिवर्तनीय वस्तुओं और उच्च क्रम वाले कार्यों के साथ इसे और अधिक "मुहावरेदार" लिखें, और यह थोड़ा धीमा और थोड़ा बड़ा होगा। इस नियम के अंगूठे का एक अपवाद यह है कि जेनेरिक ऑब्जेक्ट्स का उपयोग करते समय जिसमें टाइप पैरामेट @specialisedएनोटेशन का उपयोग करते हैं, यह और भी बड़ा बायटेकोड बनाएगा जो बॉक्सिंग / अनबॉक्सिंग से बचकर जावा के प्रदर्शन को आगे बढ़ा सकता है।

यह भी ध्यान देने योग्य तथ्य है कि अधिक मेमोरी / कम गति एक अपरिहार्य व्यापार-बंद है जब कोड लिखा जाता है जिसे समानांतर में चलाया जा सकता है। जियोमैटिक स्काला कोड, विशिष्ट जावा कोड की तुलना में प्रकृति में कहीं अधिक घोषणात्मक है, और अक्सर .parपूरी तरह से समानांतर होने से केवल 4 वर्ण ( ) दूर है।

तो अगर

• स्केल कोड जावा थ्रेड की तुलना में एक ही धागे में 1.25x से अधिक समय लेता है
• इसे आसानी से 4 कोर में विभाजित किया जा सकता है (अब लैपटॉप में भी सामान्य)
• मूल जावा के समानांतर रन समय (1.24 / 4 =) के लिए

क्या आप तब कहेंगे कि स्काला कोड अब तुलनात्मक रूप से 25% धीमा है, या 3x तेज है?

सही उत्तर इस बात पर निर्भर करता है कि आप "प्रदर्शन" को कैसे परिभाषित करते हैं :)

Comments

संयोग से, आप उल्लेख करना चाह सकते हैं कि .par2.9 में है।

— रेक्स केर

>> क्या आप कहेंगे कि स्काला कोड अब तुलनात्मक रूप से 25% धीमा है, या 3x तेज है? << मैं कहूंगा कि बहु-थ्रेडेड जावा कोड की तुलना में आपका काल्पनिक गुण क्यों नहीं है?

— .गौई

@igouy - बिंदु यह है कि काल्पनिक कोड मौजूद नहीं है, "तेज" जावा कोड की अनिवार्य प्रकृति समानांतर बनाने के लिए बहुत कठिन है, जैसे कि लागत / लाभ अनुपात का मतलब है कि यह बिल्कुल भी होने की संभावना नहीं है। मुहावरेदार स्काला, दूसरे हाथ पर, प्रकृति में कहीं अधिक कथात्मक जा रहा है अक्सर समवर्ती एक छोटी सी परिवर्तन से अधिक नहीं के साथ किया जा सकता है।

— केविन राइट

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

— केविन राइट

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

— केविन राइट

Answer 4

कंप्यूटर भाषा बेंचमार्क गेम:

स्पीड टेस्ट जावा / स्काला 1.71 / 2.25

मेमोरी टेस्ट जावा / स्केला 66.55 / 80.81

तो, इस बेंचमार्क का कहना है कि जावा 24% तेज है और स्काला 21% अधिक मेमोरी का उपयोग करता है।

ऑल-इन-ऑल यह कोई बड़ी बात नहीं है और वास्तविक दुनिया के ऐप्स में कोई फर्क नहीं होना चाहिए, जहां अधिकांश समय डेटाबेस और नेटवर्क द्वारा खपत होती है।

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

Comments

कोड आकार जावा / स्केला ३.३ ९ / २.२१

— हमार

इस तरह की संख्याओं से सावधान रहें, वे बहुत सटीक आवाज करते हैं जबकि वास्तव में उनका मतलब लगभग कुछ भी नहीं है। ऐसा नहीं है कि स्काला हमेशा जावा से औसतन 24% तेज है, आदि

— जेसपर

Afaik उद्धृत संख्याएं विपरीत दर्शाती हैं: जावा स्कैला की तुलना में 24% तेज है। लेकिन जैसा कि आप कहते हैं - वे माइक्रोएन्चमार्क हैं, जो वास्तविक ऐप्स में क्या हो रहा है, उससे मेल नहीं खाते। और अलग-अलग भाषाओं में अलग-अलग तरीका या समस्या समाधान अंत में कम तुलनीय कार्यक्रमों को जन्म दे सकता है।

— उपयोगकर्ता अज्ञात

"अगर स्काला आपको और आपकी टीम को बना देता है ..." निचला रेखा: आपको पता चल जाएगा कि :-) से पहले नहीं

— igouy

बेंचमार्क गेम हेल्प पेज "2 भाषा कार्यान्वयन के लिए प्रोग्राम की गति और आकार की तुलना" करने का एक उदाहरण प्रदान करता है। स्काला और जावा के लिए उपयुक्त तुलनात्मक वेब पेज है - shootout.alioth.debian.org/u64q/scala.php

— igouy

Answer 5

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

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

मैं अपेक्षाकृत स्काला के नया हूँ लेकिन इसके बारे में लग रहा है (एक साल या के बारे में), इस प्रकार अब तक, यह है कि यह आप के लिए अनुमति देता है ठुकराने डिजाइन, कार्यान्वयन और निष्पादन के कई पहलुओं को अपेक्षाकृत आसानी से (पर्याप्त पृष्ठभूमि पढ़ने और प्रयोग के साथ :)

आस्थगित डिजाइन विशेषताएं:

• सार प्रकार
• स्पष्ट रूप से टाइप किए गए स्व संदर्भ
• दृश्य
• mixins

आस्थगित कार्यान्वयन विशेषताएं:

• वैरिएंट एनोटेशन
• यौगिक प्रकार
• स्थानीय प्रकार का आविष्कार

आस्थगित निष्पादन सुविधाएँ: (क्षमा करें, कोई लिंक नहीं)

• थ्रेड-सुरक्षित आलसी मूल्य
• दर्रा--नाम से
• मोनाडिक सामान

ये विशेषताएं, मेरे लिए, वे हैं जो हमें तेज, तंग अनुप्रयोगों के मार्ग को फैलाने में मदद करती हैं।

---

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

यहाँ मुझे लगता है कि अपने उदाहरण के लिए सेब के बराबर सेब अधिक है:

val bigEnough = array.collect({
    case k: String if k.length > 2 && mapping.contains(k) => mapping(k)
})

कोई मध्यस्थ संग्रह, कोई Optionउदाहरण आदि भी यह संग्रह प्रकार को संरक्षित करता है इसलिए bigEnoughप्रकार है Array[File]- Array's collectकार्यान्वयन शायद श्री केर के जावा कोड क्या करता है की तर्ज पर कुछ कर रहा है।

ऊपर बताई गई आस्थगित डिज़ाइन विशेषताएँ, जो कि Scala के संग्रह API डेवलपर्स को भी भविष्य में रिलीज़ में बिना API को तोड़े हुए उस तीव्र Array-विशिष्ट संग्रह कार्यान्वयन को कार्यान्वित करने की अनुमति देंगी। यह वही है जो मैं गति के मार्ग को फैलाने के साथ संदर्भित कर रहा हूं।

इसके अलावा:

val bigEnough = array.withFilter(_.length > 2).flatMap(mapping.get)

withFilterविधि है कि मैं यहाँ का उपयोग किया है बजाय filterफिक्स मध्यवर्ती संग्रह समस्या लेकिन वहां अभी भी विकल्प उदाहरण मुद्दा है।

---

स्काला में सरल निष्पादन की गति का एक उदाहरण लॉगिंग के साथ है।

जावा में हम कुछ इस तरह लिख सकते हैं:

if (logger.isDebugEnabled())
    logger.debug("trace");

स्काला में, यह सिर्फ:

logger.debug("trace")

क्योंकि स्काला में डिबग करने के लिए संदेश पैरामीटर का प्रकार " => String" है जो मैं एक पैरामीटर-कम फ़ंक्शन के रूप में सोचता हूं जो मूल्यांकन किए जाने पर निष्पादित होता है, लेकिन जिसे प्रलेखन पास-बाय-नाम कहता है।

EDIT {स्काला में कार्य ऑब्जेक्ट हैं इसलिए यहां एक अतिरिक्त ऑब्जेक्ट है। मेरे काम के लिए, एक तुच्छ वस्तु का वजन एक लॉग संदेश की संभावना का मूल्यांकन करने की संभावना को दूर करने के लायक है। }

यह कोड को तेज नहीं बनाता है, लेकिन यह तेजी से होने की अधिक संभावना बनाता है और हमें अन्य लोगों के कोड के माध्यम से जाने और सफाई करने का अनुभव कम होता है।

मेरे लिए, यह स्काला के भीतर एक सुसंगत विषय है।

---

हार्ड कोड कैप्चर करने में विफल रहता है कि स्केला क्यों तेज है, हालांकि यह थोड़ा संकेत देता है।

मुझे लगता है कि यह कोड री-यूज़ का संयोजन है और स्काला में कोड क्वालिटी की छत है।

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

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

Comments

आपका लॉगिंग सामान स्काला के प्रदर्शन नुकसान के लिए एक अच्छा उदाहरण है: logger.debug ("ट्रेस") पैरामीटर-कम फ़ंक्शन के लिए एक नई वस्तु बनाता है।

— jcsahnwaldt

वास्तव में - यह मेरे संबंधित बिंदु को कैसे प्रभावित करता है?

— सेठ

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

— सेठ

ठीक है, मैंने इसे फिर से पढ़ा है और मैंने लिखा है, "सरल निष्पादन की गति" - मैं एक नोट जोड़ूंगा। शुभ अंक :)

— सेठ

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

— एलॉफ

Answer 6

इस विषय पर @higherkinded ons प्रस्तुति - स्काला प्रदर्शन विचार जो कुछ जावा / स्काला तुलना करता है।

उपकरण:

• ScalaMeter
• स्केला-बेंच मार्किंग-टेम्पलेट

महान ब्लॉगपोस्ट:

• नानोटाइम को सौंपना

Answer 7

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

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

Comments

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

— उपयोगकर्ता अज्ञात

@user अज्ञात - "एक-लूप लूप हो सकता है, एक शब्दार्थ-लूप की तुलना में स्कैला में बहुत तेजी से हो सकता है" - ध्यान दें कि उन स्कैला बेंचमार्क गेम प्रोग्राम को लूप्स के साथ लिखा जाता है।

— इगौई

@igouy: मैंने इस माइक्रोबेनमार्क के परिणामों के बारे में बात नहीं की, लेकिन तर्क के बारे में। एक सच्चा कथन, Java and Scala both compile down to JVM bytecode, जो उस soप्रश्न के कथन के साथ जोड़ दिया गया था जिसे diffence isn't that big.मैं दिखाना चाहता था, कि soयह केवल एक लफ्फाजी की चाल है, न कि एक तर्कपूर्ण निष्कर्ष।

— उपयोगकर्ता अज्ञात

आश्चर्यजनक रूप से उच्च मतों के साथ आश्चर्यजनक रूप से गलत उत्तर।

— शबून

Answer 8

जावा उदाहरण वास्तव में विशिष्ट एप्लिकेशन प्रोग्राम के लिए एक मुहावरा नहीं है। ऐसा अनुकूलित कोड सिस्टम लाइब्रेरी विधि में पाया जा सकता है। लेकिन तब यह सही प्रकार की एक सरणी का उपयोग करेगा, अर्थात फ़ाइल [] और एक IndexOutOfBoundsException नहीं फेंकेंगे। (गिनती और जोड़ने के लिए अलग-अलग फिल्टर की स्थिति)। मेरा संस्करण (हमेशा!) घुंघराले ब्रेसिज़ के साथ होगा (क्योंकि मैं एक बग को खोजने में एक घंटा बिताना पसंद नहीं करता हूं जिसे 2 सेकंड बचाने के लिए ग्रहण में एक ही कुंजी को मारने के लिए पेश किया गया था):

List<File> bigEnough = new ArrayList<File>();
for(String s : array) {
  if(s.length() > 2) {
    File file = mapping.get(s);
    if (file != null) {
      bigEnough.add(file);
    }
  }
}

लेकिन मैं आपको अपनी वर्तमान परियोजना से कई अन्य बदसूरत जावा कोड उदाहरण ला सकता हूं। मैंने कॉमन कॉपी से बचने की कोशिश की और कोडिंग की शैली को आम संरचनाओं और व्यवहार से अलग करके देखा।

मेरे अमूर्त DAO बेस क्लास में मैं सामान्य कैशिंग तंत्र के लिए एक सार इनर क्लास है। प्रत्येक ठोस मॉडल ऑब्जेक्ट प्रकार के लिए अमूर्त DAO बेस क्लास का एक उपवर्ग होता है, जिसमें आंतरिक वर्ग को उपविधि के लिए एक कार्यान्वयन प्रदान करने के लिए उप-वर्गित किया जाता है जो डेटाबेस से लोड होने पर व्यावसायिक ऑब्जेक्ट बनाता है। (हम ORM टूल का उपयोग नहीं कर सकते क्योंकि हम एक स्वामित्व API के माध्यम से किसी अन्य सिस्टम तक पहुँच प्राप्त करते हैं।)

यह उपवर्ग और तात्कालिकता कोड जावा में बिल्कुल भी स्पष्ट नहीं है और स्काला में बहुत पठनीय होगा।