क्या किसी के पास Xamarin C # और Java में लिखे Android ऐप्स के प्रदर्शन की तुलना करने के लिए बेंचमार्क (कोड और परिणाम) हैं? [बन्द है]

Question

मुझे Xamarin का दावा है कि Android पर उनके मोनो कार्यान्वयन और उनके C # संकलित ऐप्स जावा कोड से अधिक तेज़ हैं। क्या किसी ने इस तरह के दावों को सत्यापित करने के लिए विभिन्न एंड्रॉइड प्लेटफार्मों पर बहुत समान जावा और सी # कोड पर वास्तविक बेंचमार्क प्रदर्शन किया, कोड और परिणाम पोस्ट कर सकता है?

18 जून 2013 को जोड़ा गया

चूंकि कोई जवाब नहीं था और दूसरों द्वारा किए गए ऐसे बेंचमार्क नहीं पा सके, इसलिए मैंने खुद टेस्ट करने का फैसला किया। दुर्भाग्य से, मेरा प्रश्न "लॉक" है, इसलिए मैं इसे उत्तर के रूप में पोस्ट नहीं कर सकता, केवल प्रश्न को संपादित कर सकता हूं। कृपया इस प्रश्न को पुनः खोलने के लिए मतदान करें। C # के लिए, मैंने Xamarin.Android Ver का उपयोग किया। 4.7.09001 (बीटा)। स्रोत कोड, सभी डेटा जो मैंने परीक्षण और संकलित एपीके पैकेज के लिए उपयोग किया है, वे GitHub पर हैं:

जावा: https://github.com/gregko/TtsSetup_Java

C #: https://github.com/gregko/TtsSetup_C_sharp

यदि कोई अन्य उपकरणों या एमुलेटर पर मेरे परीक्षण को दोहराना चाहेगा, तो मुझे परिणाम जानने के लिए दिलचस्पी होगी।

मेरे परीक्षण से परिणाम

मैंने अपने वाक्य निष्कर्षक वर्ग को C # (मेरे @Voice अलाउड रीडर ऐप से) पोर्ट किया और अंग्रेजी, रूसी, फ्रेंच, पोलिश और चेक भाषाओं में 10 HTML फ़ाइलों पर कुछ परीक्षण चलाए। प्रत्येक रन को सभी 10 फाइलों पर 5 बार किया गया था, और 3 अलग-अलग उपकरणों और एक एमुलेटर के लिए कुल समय नीचे पोस्ट किया गया है। मैंने "रिलीज़" का परीक्षण किया, केवल डिबगिंग सक्षम किए बिना बनाता है।

एचटीसी नेक्सस वन एंड्रॉयड 2.3.7 (एपीआई 10) - सायनोजेनमॉड रोम

जावा: ग्रैंड कुल समय (5 रन): 12361 एमएस, फाइल रीडिंग कुल के साथ: 13304 एमएस

सी #: ग्रांड कुल समय (5 रन): 17504 एमएस, फाइल रीडिंग कुल के साथ: 17956 एमएस

सैमसंग गैलेक्सी S2 SGH-I777 (एंड्रॉइड 4.0.4, एपीआई 15) - CyanogenMod ROM

जावा: ग्रांड कुल समय (5 रन): 8947 एमएस, फाइल पढ़ने के साथ कुल: 9186 एमएस

सी #: ग्रांड कुल समय (5 रन): 9884 एमएस, फाइल रीडिंग कुल के साथ: 10247 एमएस

सैमसंग GT-N7100 (एंड्रॉइड 4.1.1 जेलीबीन, एपीआई 16) - सैमसंग रोम

जावा: ग्रैंड टोटल टाइम (5 रन): 9742 एमएस, फाइल रीडिंग कुल: 10111 एमएस

सी #: ग्रांड कुल समय (5 रन): 10459 एमएस, फाइल रीडिंग कुल के साथ: 10696 एमएस

एमुलेटर - इंटेल (एंड्रॉइड 4.2, एपीआई 17)

जावा: ग्रैंड टोटल टाइम (5 रन): 2699 एमएस, फाइल रीडिंग कुल के साथ: 3127 एमएस

C #: ग्रैंड टोटल टाइम (5 रन): 2049 एमएस, फाइल रीडिंग कुल के साथ: 2182 एमएस

एमुलेटर - इंटेल (एंड्रॉइड 2.3.7, एपीआई 10)

जावा: ग्रैंड टोटल टाइम (5 रन): 2992 एमएस, फाइल रीडिंग कुल के साथ: 3591 एमएस

C #: ग्रैंड टोटल टाइम (5 रन): 2049 एमएस, फाइल रीडिंग कुल के साथ: 2257 एमएस

एमुलेटर - आर्म (एंड्रॉइड 4.0.4, एपीआई 15)

जावा: ग्रैंड टोटल टाइम (5 रन): 41751 एमएस, फाइल रीडिंग कुल के साथ: 43866 एमएस

सी #: ग्रैंड टोटल टाइम (5 रन): 44136 एमएस, फाइल रीडिंग कुल: 45109 एमएस

छोटी चर्चा

मेरे परीक्षण कोड में मुख्य रूप से टेक्स्ट पार्सिंग, रिप्लेसिंग और रेगेक्स खोजें शामिल हैं, शायद अन्य कोड (जैसे अधिक संख्यात्मक संचालन) के लिए परिणाम भिन्न होंगे। ARM प्रोसेसर वाले सभी डिवाइसों पर, Java ने Xamarin C # कोड से बेहतर प्रदर्शन किया। सबसे बड़ा अंतर Android 2.3 के तहत था, जहां C # कोड लगभग होता है। जावा गति का 70%।

इंटेल एमुलेटर पर (इंटेल HAX तकनीक के साथ, एमुलेटर तेज पुण्य मोड में चलता है), Xamarin C # कोड जावा के मुकाबले मेरा नमूना कोड बहुत तेजी से चलाता है - लगभग 1.35 समय तेजी से। शायद मोनो वर्चुअल मशीन कोड और लाइब्रेरी एआरएम की तुलना में इंटेल पर बहुत बेहतर रूप से अनुकूलित हैं?

8 जुलाई 2013 को संपादित करें

मैंने अभी Genymotion Android एमुलेटर स्थापित किया है, जो Oracle VirtualBox में चलता है, और फिर से यह एआरएम प्रोसेसर का अनुकरण न करते हुए देशी इंटेल प्रोसेसर का उपयोग करता है। Intel HAX एमुलेटर के साथ, फिर से C # यहां बहुत तेजी से चलता है। यहाँ मेरे परिणाम हैं:

जीनोम्यूलेटर एमुलेटर - इंटेल (एंड्रॉइड 4.1.1, एपीआई 16)

जावा: ग्रैंड टोटल टाइम (5 रन): 2069 एमएस, फाइल रीडिंग कुल के साथ: 2248 एमएस

सी #: ग्रैंड टोटल टाइम (5 रन): 1543 एमएस, फाइल रीडिंग कुल के साथ: 1642 एमएस

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

बीएन नुक्कड़ एक्सडी +, एआरएम (एंड्रॉयड 4.0)

जावा: ग्रैंड टोटल टाइम (5 रन): 8103 एमएस, फाइल रीडिंग कुल के साथ: 8569 एमएस

C #: ग्रैंड टोटल टाइम (5 रन): 7951 एमएस, फाइल रीडिंग कुल के साथ: 8161 एमएस

वाह! C # अब जावा से बेहतर है? मेरे गैलेक्सी नोट 2 पर परीक्षण दोहराने का फैसला:

सैमसंग गैलेक्सी नोट 2 - ARM (Android 4.1.1)

जावा: ग्रैंड टोटल टाइम (5 रन): 9675 एमएस, फाइल रीडिंग कुल: 10028 एमएस

सी #: ग्रांड कुल समय (5 रन): 9911 एमएस, फाइल रीडिंग कुल के साथ: 10104 एमएस

यहाँ C # केवल थोड़ा धीमा प्रतीत होता है, लेकिन इन नंबरों ने मुझे एक विराम दिया: Nook HD + की तुलना में समय अधिक क्यों है, भले ही नोट 2 में तेज प्रोसेसर है? जवाब: बिजली की बचत मोड। नुक्कड़ पर, यह नोट 2 पर सक्षम था - सक्षम। पावर सेविंग मोड डिसेबल (सक्षम के साथ, यह प्रोसेसर की गति को भी सीमित करता है) के साथ परीक्षण करने का निर्णय लिया गया:

सैमसंग गैलेक्सी नोट 2 - एआरएम (एंड्रॉइड 4.1.1), बिजली की बचत अक्षम

जावा: ग्रैंड कुल समय (5 रन): 7153 एमएस, फाइल रीडिंग कुल के साथ: 7459 एमएस

सी #: ग्रांड कुल समय (5 रन): 6906 एमएस, फाइल रीडिंग कुल के साथ: 7070 एमएस

अब, आश्चर्यजनक रूप से, एआर प्रोसेसर पर जावा की तुलना में सी # थोड़ा तेज है। बड़ा सुधार!

12 जुलाई 2013 को संपादित करें

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

जावा: ग्रैंड टोटल टाइम (5 रन): 3292 एमएस, फाइल रीडिंग कुल के साथ: 3454 एमएस

मूल अंगूठे: कुल समय (5 रन): 537 एमएस, फाइल पढ़ने के साथ कुल: 657 एमएस

मूल भुजा: ग्रैंड कुल समय (5 रन): 458 एमएस, फाइल पढ़ने के साथ कुल: 587 एमएस

मेरे विशेष परीक्षण के लिए लग रहा है, मूल कोड जावा की तुलना में 6 से 7 गुना तेज है। कैविएट: एंड्रॉइड पर std :: regex क्लास का उपयोग नहीं कर सकता था, इसलिए मुझे पैराग्राफ ब्रेक या एचटीएमएल टैग की खोज करने के लिए अपनी विशेष दिनचर्या लिखनी थी। रेगेक्स का उपयोग करते हुए पीसी पर एक ही कोड के मेरे शुरुआती परीक्षण, जावा की तुलना में लगभग 4 से 5 गुना तेज थे।

ओह! कच्ची मेमोरी को चार * या व्हचर * पॉइंटर्स के साथ फिर से जागना, मुझे तुरंत 20 साल छोटा लगा! :)

15 जुलाई 2013 को संपादित करें

(नीचे देखें, Dot42 के साथ बेहतर परिणाम के लिए 7/30/2013 के संपादन के साथ)

कुछ कठिनाई के साथ, मैंने अपने C # परीक्षणों को Dot42 (संस्करण 1.0.1.71 बीटा), Android के लिए एक और C # प्लेटफ़ॉर्म पोर्ट करने में कामयाब रहा। प्रारंभिक परिणाम बताते हैं कि Dot42 कोड इंटेल एंड्रॉइड एमुलेटर पर Xamarin C # (v। 4.7.11) की तुलना में लगभग 3x (3 गुना) धीमा है। एक समस्या यह है कि Dot42 में System.Text.RegularExpressions वर्ग में स्प्लिट () फ़ंक्शन नहीं है जो मैंने Xamarin परीक्षणों में उपयोग किया था, इसलिए मैंने इसके बजाय Java.Util.Regex वर्ग और Java.Util .egex.Pattern.Split () का उपयोग किया। , इसलिए कोड में इस विशेष स्थान में, यह छोटा अंतर है। हालांकि एक बड़ी समस्या नहीं होनी चाहिए। Dot42 Dalvik (DEX) कोड के लिए संकलित करता है, इसलिए यह मूल रूप से एंड्रॉइड पर जावा के साथ सहयोग करता है, Xamarin की तरह C # से जावा तक महंगे इंटरोप की आवश्यकता नहीं है।

तुलना के लिए, मैं एआरएम उपकरणों पर परीक्षण भी चलाता हूं - यहां डॉट 42 कोड "केवल" है जो ज़मारिन सी # की तुलना में धीमा है। यहाँ मेरे परिणाम हैं:

एचटीसी नेक्सस वन एंड्रॉयड 2.3.7 (एआरएम)

जावा: ग्रैंड टोटल टाइम (5 रन): 12187 एमएस, फाइल रीडिंग कुल: 13200 एमएस

ज़ामरीन सी #: ग्रैंड टोटल टाइम (5 रन): 13935 एमएस, फाइल रीडिंग कुल के साथ: 14465 एमएस

Dot42 C #: ग्रैंड टोटल टाइम (5 रन): 26000 एमएस, फाइल रीडिंग कुल के साथ: 27168 एमएस

सैमसंग गैलेक्सी नोट 2, एंड्रॉयड 4.1.1 (एआरएम)

जावा: ग्रैंड टोटल टाइम (5 रन): 6895 एमएस, फाइल रीडिंग कुल के साथ: 7275 एमएस

ज़ामरीन सी #: ग्रैंड टोटल टाइम (5 रन): 6466 एमएस, फाइल पढ़ने के साथ कुल: 6720 एमएस

Dot42 C #: ग्रैंड टोटल टाइम (5 रन): 11185 एमएस, फाइल रीडिंग कुल के साथ: 11843 एमएस

इंटेल एमुलेटर, एंड्रॉइड 4.2 (x86)

जावा: ग्रैंड कुल समय (5 रन): 2389 एमएस, फाइल पढ़ने के साथ कुल: 2770 एमएस

ज़ामरीन सी #: ग्रैंड टोटल टाइम (5 रन): 1748 एमएस, फाइल रीडिंग कुल के साथ: 1933 एमएस

Dot42 C #: ग्रैंड टोटल टाइम (5 रन): 5150 एमएस, फाइल रीडिंग कुल के साथ: 5459 एमएस

मेरे लिए, यह भी ध्यान रखना दिलचस्प है कि Xamarin C # नए ARM डिवाइस पर Java की तुलना में थोड़ा तेज है और पुराने Nexus One पर थोड़ा धीमा है। यदि कोई भी इन परीक्षणों को चलाना चाहे, तो कृपया मुझे बताएं और मैं GitHub के स्रोतों को अपडेट करूंगा। इंटेल प्रोसेसर के साथ एक वास्तविक एंड्रॉइड डिवाइस से परिणाम देखना विशेष रूप से दिलचस्प होगा।

अपडेट 7/26/2013

बस एक त्वरित अद्यतन, नवीनतम Xamarin.Android 4.8 के साथ बेंचमार्क ऐप्स द्वारा फिर से संकलित किया गया, और आज जारी किए गए डॉट42 1.0.1.72 अपडेट के साथ भी - पहले बताए गए परिणामों से कोई महत्वपूर्ण परिवर्तन नहीं।

अद्यतन 7/30/2013 - dot42 के लिए बेहतर परिणाम

मेरे जावा कोड के C # पर रॉबर्ट के (डॉट 42 निर्माताओं से) पोर्ट के साथ डॉट 42 का पुनः परीक्षण किया। Xamarin के लिए शुरू में किए गए मेरे C # पोर्ट में, मैंने कुछ मूल जावा वर्गों को प्रतिस्थापित किया, जैसे ListArray, List वर्ग के मूल निवासी C # के साथ, आदि। रॉबर्ट के पास मेरा Dot42 स्रोत कोड नहीं था, इसलिए उन्होंने इसे जावा से फिर से पोर्ट किया और अन्य जावा कक्षाओं का उपयोग किया। ऐसी जगहें, जो Dot42 को फायदा पहुंचाती हैं, मुझे लगता है क्योंकि यह Dalvik VM में चलती है, जावा की तरह, और मोनो में, ज़मरीन की तरह नहीं। अब Dot42 के परिणाम काफी बेहतर हैं। यहाँ मेरे परीक्षण से एक लॉग है:

7/30/2013 - Dot42 C # में अधिक जावा कक्षाओं के साथ Dot42 परीक्षण

इंटेल एमुलेटर, एंड्रॉइड 4.2

Dot42, ग्रेग का कोड StringBuilder.Replace () (Xamarin के रूप में) का उपयोग करते हुए:
ग्रैंड कुल समय (5 रन): 3646 ms, फ़ाइल पढ़ने का कुल योग: 3830 ms

Dot42, ग्रेग का कोड String.Replace () का उपयोग करते हुए (जैसा कि जावा और रॉबर्ट के कोड में है):
ग्रैंड कुल समय (5 रन): 3027 एमएस, फाइल रीडिंग कुल के साथ: 3206 एमएस

Dot42, रॉबर्ट कोड:
ग्रैंड टोटल टाइम (5 रन): 1781 एमएस, फाइल रीडिंग कुल: 1999 एमएस

ज़मीरिन:
ग्रैंड कुल समय (5 रन): 1373 एमएस, फ़ाइल पढ़ने के साथ कुल: 1505 एमएस

जावा:
ग्रैंड टोटल टाइम (5 रन): 1841 एमएस, फाइल रीडिंग कुल: 2044 एमएस

एआरएम, सैमसंग गैलेक्सी नोट 2, बिजली की बचत, एंड्रॉइड 4.1.1

Dot42, ग्रेग का कोड StringBuilder.Replace () (Xamarin के रूप में) का उपयोग करते हुए:
ग्रैंड कुल समय (5 रन): 10875 ms, फ़ाइल पढ़ने का कुल योग: 11280 ms

Dot42, ग्रेग का कोड String.Replace () और जावा (रॉबर्ट्स कोड के रूप में) का उपयोग कर:
ग्रैंड कुल समय (5 रन): 9710 एमएस, फाइल पढ़ने के साथ कुल: 10097 एमएस

Dot42, रॉबर्ट कोड:
ग्रांड कुल समय (5 रन): 6279 एमएस, फ़ाइल पढ़ने के साथ कुल: 6622 एमएस

ज़मीरिन:
ग्रैंड कुल समय (5 रन): 6201 एमएस, फ़ाइल पढ़ने के साथ कुल: 6476 एमएस

जावा:
ग्रैंड टोटल टाइम (5 रन): 7141 एमएस, फाइल रीडिंग कुल के साथ: 7479 एमएस

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

ग्रेग

Comments

नेक्सस 7 4.2.2 पर DEBUG मोड स्ट्रिंग्स और xamarin अल्फा 9 पर कुछ अनुकूलन के साथ: कुल समय: 3907 एमएस, फ़ाइल पढ़ने के साथ कुल: 4016. "5 रन" का क्या अर्थ है?

— सॉफ्टलियन जूल 5'13

"यह प्रश्न संभवतः बहस, बहस, मतदान, या विस्तारित चर्चा की संभावना है" <- ऊपर देखें;)

— LearnCocos2D

@ LearnCocos2D - मैं केवल ठोस परिणाम और संख्या, अर्थात तथ्यों की रिपोर्ट कर रहा हूँ। सज्जन लोग तथ्यों पर विवाद नहीं करते हैं :)

— gregko

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

— LearnCocos2D

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

— LearnCocos2D

Answer 1

हाँ, एंड्रॉइड में उपयोग किए जाने वाले Google के Dalvik की तुलना में Xamarin की मोनो वर्चुअल मशीन अधिक प्रभावशाली है। मैंने इसे HTC फ्लायर और एसर आइकोनिया टैब टैबलेट्स के साथ परीक्षण किया है जो जावा डेल्विक के खिलाफ मोनो के माध्यम से एंड्रॉइड के सी # पोर्ट को बेंचमार्क करने के लिए, एंड्रॉइड के सी # कार्यान्वयन के साथ और वास्तव में जावा-आधारित डाल्विक को छोटा कर रहा है।

Comments

@PeterLawrey, कृपया सवाल का मेरा अपडेट देखें। मैं अपने वास्तविक जीवन जावा कोड के कुछ हिस्से को C # में पोर्ट करने और बेंचमार्क चलाने का इरादा रखता हूं, फिर उन्हें यहां पोस्ट करें - अगर वे मेरे सवाल को फिर से खोलते हैं, तो जैसे कि एसओ विजिनेस ने इसे लगभग तुरंत बंद कर दिया।

— ग्रोग्को

@PeterLawrey - मैंने अब अपने परीक्षण किए और स्टैकऑवरफ़्लो पर परिणाम पोस्ट किए, लेकिन स्वयं प्रश्न के भीतर, क्योंकि यह अभी भी "लॉक" बना हुआ है और एक उत्तर पोस्ट नहीं कर सकता है। यदि आप कर सकते हैं, तो कृपया प्रश्न को पुनः खोलने के लिए अपना वोट जोड़ें। परिणाम दिलचस्प हैं, एआरएम जावा ने हैंड्स-डाउन जीता, इंटेल पर - मोनो में कोड # बहुत तेज है।

— ग्रैग्को

@gregko यह ध्यान देने योग्य है कि आप सी # को तेजी से अनुकरण करते हुए देखते हैं, लेकिन असली फोन पर जावा तेज है। मेरे लिए यह एक महत्वपूर्ण अंतर है। मैं एमुलेटर के प्रदर्शन के बारे में चिंता नहीं करूँगा, वास्तव में मैं आपको सुझाव दूंगा कि एमुलेटर असली चीज़ की तरह धीमा / तेज़ होना चाहिए। मैंने फिर से खुलने के लिए मतदान किया है।

— पीटर लॉरी

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

— क्रिस्टोफर

यह उत्तर बिना किसी स्पष्टीकरण के बेकार है कि आपने इन परीक्षणों या परीक्षा परिणामों को कैसे निष्पादित किया। जैसा कि अभी है: पूरी तरह से आधारित राय।

— रॉल्फ R

Answer 2

I came across this interesting post

https://medium.com/@harrycheung/mobile-app-performance-redux-e512be94f976#.kfbauchtz

आशा है कि यह जानकारी मदद करती है।

Answer 3

हमने हाल ही में एक ऐप के लिए ज़मारिन का उपयोग करके जांच की। हमने अपने ऐप के विंडोज आरटी संस्करण के लिए पहले ही लिखे C # कोड का उपयोग कर लिया। कुछ विशिष्ट विवरणों को Android संस्करण के लिए फिर से लिखना पड़ा।

हमने जो खोज की है वह यह है कि Xamarin C # में I / O जावा की तुलना में लगभग 2x धीमा है। हमारा ऐप भारी है I / O बाध्य है। हमने अभी तक इसके कारण का पता नहीं लगाया है, लेकिन फिलहाल हम मान रहे हैं कि यह दलदल के कारण है। जबकि हम ज्यादातर समय मोनो वीएम के अंदर रहने की कोशिश करते हैं, हम नहीं जानते कि मोनो वास्तव में डिस्क तक कैसे पहुंचता है।

यह भी बता रहा है कि हमारा C # कोड SQLite.NET ( https://github.com/praeclarum/sqlite-net ) का उपयोग करता है । SQLite.NET कोड का उपयोग करने वाले आइडेंटिफाइड भ्रूण भी Android के जावा SQLite रैपर का उपयोग करने से 2x धीमा हैं। स्रोत कोड को देखने के बाद, यह सीधे सी। Dll से जुड़ता हुआ दिखाई देता है, इसलिए मुझे नहीं पता कि यह इतना धीमा क्यों है। एक संभावना यह है कि मूल से जावा तक की तारबंदी एंड्रॉइड पर मूल से तेज # Xamarin पर हो सकती है।

Comments

यह "बाइंडिंग" के साथ भी होने की बहुत संभावना है, ज़ामेरिन को सिस्टम के साथ बातचीत करने की आवश्यकता है। डिफ़ॉल्ट रूप से प्रत्येक और हर सिस्टम कॉल जावा क्लास में जाता है, लेकिन मोनो वीएम को सौंपने की आवश्यकता होती है, जिसमें समय लगता है। यही उलटा भी होता है। मैंने अपने उत्तर में इसे थोड़ा और समझाया है: stackoverflow.com/a/46973819/1052697

— रॉल्फ

Answer 4

यह एक और अद्यतन ब्लॉग पोस्ट है जिसे मैं आपके साथ साझा करना चाहूंगा । वह Xamarin की तुलना IO और Android दोनों पर देशी कोड और कॉर्डोवा से करता है।

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

का आनंद लें!

संपादित करें: मैंने मृत लिंक को अपडेट किया और मैंने देखा कि एक भाग 2 है

Answer 5

यहाँ कुछ संकेत मुझे देशी, Xamarin और Xamarin के बीच एक अन्य परीक्षण में मिले हैं। दो समाधानों पर परीक्षण (IOS प्रदर्शन भी शामिल हैं) समाधान:

सैमसंग गैलेक्सी ए 7 : एंड्रॉइड ओएस संस्करण: 6.0 सेंट्रल-प्रोसेसिंग यूनिट: ऑक्टा-कोर 1.9 गीगाहर्ट्ज़ कॉर्टेक्स-ए 53 रैम: 3 जीबी डिस्प्ले रिज़ॉल्यूशन: 1920 × 1080

iPhone 6s : iOS संस्करण: 10.3.3 सेंट्रल-प्रोसेसिंग यूनिट: डुअल-कोर 1.84 गीगाहर्ट्ज ट्विस्टर रैम: 2 जीबी डिस्प्ले रिज़ॉल्यूशन: 1334 × 750

तुलना कुछ सामान्य विशेषताओं पर की जाती है, हर एक अपने आवेदन के साथ:

- Basic “Hello World”
- REST API
- JSON Serialization/Deserialization
- Photo Loading
- SQL Database Insert and Get All

प्रत्येक परीक्षण को कई बार दोहराया जाता है, ग्राफ़ औसत परिणाम दिखाते हैं।

---

नमस्ते दुनिया

---

बाकी एपीआई

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

---

JSON ऑपरेशंस टेस्ट, सभी Xamarin ऐप्स में JSON ऑब्जेक्ट्स को क्रमबद्ध करने और उन्हें अलग करने के लिए Newtonsoft Json.net फ्रेमवर्क का उपयोग करके किया गया है। जैक्सन और जीएसओएन: दो मूल पुस्तकालयों का उपयोग करके मूल एंड्रॉइड क्रमबद्धता और डीरिएरलाइज़ेशन का परीक्षण किया गया।

दो रन बनाये जाते हैं, एक स्क्रैच से पहला और दूसरा कैश्ड इन्फोस और ऑपरेशंस वाला

प्रथम रन :

(मूल iOS JSON ऑपरेशंस इस टेस्ट btw को मार रहा है, और Xamarin इसे दूसरे में जोड़ता है)

---

फोटो संचालन

तीन अलग-अलग प्रस्तावों के साथ छवियों पर पहला भार:

Resolution – 858×569, Size – 868Kb
Resolution – 2575×1709, Size – 8Mb
Resolution – 4291×2848, Size – 28.9Mb

इस परीक्षण के लिए Xamarin.Forms परिणामों के बारे में कुछ अनिश्चित लग रहा था, इसलिए यह ग्राफ़ में शामिल नहीं है।

---

SQLite संचालन

दो ऑपरेशन परीक्षण किए गए:

BulkInsert: Loading rows of data into a database table.
GetAll: Retrieving all data from the database.

10,000 रिकॉर्ड वाले डेटाबेस के साथ। सभी ऑपरेशन आंतरिक रूप से उपकरणों पर संसाधित किए गए थे।

---

Xamarin मूल (Xamarin.iOS / Xamarin.Android) खुद को मूल कोड के बजाय अच्छे विकल्प के रूप में दिखाता है, जबकि Xamarin.Forms बहुत से मामलों में धीमा लगता है, लेकिन यह वास्तव में सरल अनुप्रयोगों को तेजी से विकसित करने के लिए वास्तव में अच्छा समाधान हो सकता है।

पूरा परीक्षण इस स्रोत से आता है:

https://www.altexsoft.com/blog/engineering/performance-comparison-xamarin-forms-xamarin-ios-xamarin-android-vs-android-and-ios-native-applications/

मुझे अपना उत्तर बढ़ाने के लिए स्पष्टीकरण देने के लिए धन्यवाद, आशा है कि इससे थोड़ी मदद मिलेगी :)

Answer 6

प्रदर्शन

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

एंड्रॉइड nativly में कोड निष्पादित करने के लिए मल्टीपाइप फॉर्म के साथ आता है:

• रेंडरस्क्रिप्ट (CPU और GPU)
• जावा (एसडीके)
• C ++ (NDK)
• ओपनजीएल (जीपीयू)

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

लेकिन दूसरी ओर यदि आप वास्तविक जीवन के उपयोग के प्रदर्शन को मापना चाहते हैं, तो जावा तेजी से आगे बढ़ने वाला है।

Xamarin और क्यों यह धीमी हो सकती है

सादे पुराने Java अनुप्रयोगों के साथ Xamarin की तुलना करते समय, Xamarin के लिए प्रदर्शन बहुत तेजी से हो सकता है क्योंकि यह धीमा हो सकता है।

वास्तविक दुनिया के उदाहरण में Xamarin अनुप्रयोगों की जावा अनुप्रयोगों की तुलना में धीमी गति से होने की संभावना है क्योंकि कई एंड्रॉइड / जावा (सिस्टम) कॉल को तथाकथित बाइंडिंग का उपयोग करते हुए Xamarin रन-टाइम से सौंप दिया जाना चाहिए।

कुछ अलग-अलग प्रकार के बाइंडिंग हैं जिन्हें जानना महत्वपूर्ण है:

• जेएनआई (जावा नेटिव इंटरफेस): जावा कोड (एसडीके) और देशी सी ++ कोड (एनडीके) के बीच इंटरफेस करने के लिए कई एंड्रॉइड एप्लिकेशन में उपयोग किया जाने वाला बाइंडिंग।
• MCW (प्रबंधित कॉल करने योग्य आवरण): एक बाइंडिंग जो Xamarin में प्रबंधित C # कोड से जावा कोड (Android रन-टाइम) तक इंटरफ़ेस करने के लिए उपलब्ध है।
• ACW (Android Callable Wrappers): एक बाध्यकारी जो जावा कोड (एंड्रॉइड रन-टाइम) से प्रबंधित C # कोड में इंटरफ़ेस करने के लिए Xamarin में उपलब्ध है।

MCW और ACW पर अधिक यहां: https://developer.xamarin.com/guides/cross-platform/application_fundamentals/building_cross_platform_applications/part_1_-_understanding__xamarin_mobile_platform/

बाइंडिंग प्रदर्शन के मामले में बहुत महंगा है। जावा से C ++ विधि को आमंत्रित करना कॉलिंग समय में एक बहुत बड़ा ओवरहेड जोड़ता है, C ++ के भीतर से C ++ विधि को कॉल करना कई गुना तेज है।

किसी ने जेएनआई कॉल की औसत लागत पर कितने जावा संचालन की गणना करने के लिए एक प्रदर्शन परीक्षण किया: जेएनआई कॉल करने की मात्रात्मक ओवरहेड क्या है?

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

TLDR / निष्कर्ष: Xamarin को अल- सॉइंड बाइंडिंग का उपयोग करने की आवश्यकता होती है, जो समय के लिए महंगा है।

बाइंडिंग के अलावा, वास्तविक दुनिया के प्रदर्शन के बारे में बात करते समय कई अन्य कारक शामिल होते हैं, उदाहरण के लिए: बाइनरी का आकार, मेमोरी में ऐप लोड करना, मैं / ओ संचालन और कई और। इन चीजों में से कुछ की जाँच करने वाला एक ब्लॉग पोस्ट यहाँ पाया जा सकता है: https://magenic.com/thinking/mobile-development-platform-performance-part-2-native-cordova-classic-xamarin-xamarin-forms

Answer 7

यह बहुत पुराने परीक्षण हैं, लेकिन प्रासंगिक हो सकते हैं: https://github.com/EgorBo/Xamarin.Android-vs-Java

अंकगणित परीक्षण

संग्रह, जेनरिक, कस्टम मूल्य प्रकार

तार के साथ काम करना

UPD: Google Pixel 2 के साथ नया डेटा (धन्यवाद Yousha-aleayoub )

Comments

अपडेट 2018 camo.githubusercontent.com/…

— Yousha Aleayoub