C, Java से अधिक तेज़ क्यों है (Java डेवलपर के दृष्टिकोण से)

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

सूची: git
विषय: Re: क्यों Git इतना तेज है (था: Re: एरिक सिंक का ब्लॉग - git पर नोट्स,
से: "शॉन ओ। पीयर्स" <भाला () भाला! org>

जैसा कि पहले उल्लेख किया गया है, हमने वास्तव में उच्च प्रदर्शन प्राप्त करने के लिए गिट सी कोड में कई छोटे अनुकूलन किए। यहां 5%, 10% वहां, और अचानक आप पहले से 60% तेज हैं। निको [पिट्रे], लिनुस [टोरवाल्ड्स] और जूनियो [हैमनो] - उन्होंने सभी को पिछले तीन से चार वर्षों में कुछ समय गिट के व्यक्तिगत टुकड़ों को अनुकूलित करने के लिए खर्च किया, पूरी तरह से इसे जल्द से जल्द काम करने के लिए।

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

उदाहरण के लिए, JGit mmap() की कमी से ग्रस्त है, और जावा NIO MappedByteBuffer का उपयोग करते समय, हमें वास्तव में डेटा को संसाधित करने में सक्षम होने के लिए अस्थायी byte[] सरणी की प्रतिलिपि बनाने की आवश्यकता है। G में C में ऐसी कोई प्रति नहीं है। बेशक, अन्य उच्च-स्तरीय भाषाओं में, mmap विधि अधिक सुविधाजनक हो सकती है, लेकिन वे सभी भी कचरा संग्रह करते हैं, और अधिकांश भाषाएं mmap प्रबंधन को "सुरक्षा और सरलता के लिए" कचरे के संग्रहकर्ता के साथ जोड़ने का प्रयास करती हैं।

JGit जावा में अहस्ताक्षरित डेटा प्रकारों की कमी से भी ग्रस्त है। JGit में कई जगह हैं जहां हमें वास्तव में unsigned int32_t या unsigned long (अधिकतम आकार का मशीन शब्द) या unsigned char , लेकिन ये डेटा प्रकार केवल जावा में गायब हैं। एक बाइट को int में परिवर्तित करते हुए, इसे केवल अहस्ताक्षरित के रूप में प्रस्तुत करने के लिए, साइन एक्सटेंशन को रद्द करने के लिए अतिरिक्त & 0xFF ऑपरेशन की आवश्यकता है।

SHG-1 को पेश करने के लिए JGit एक प्रभावी तरीके की कमी से ग्रस्त है। C कोड में, आप केवल unsigned char[20] लिख सकते हैं और तुरंत स्ट्रिंग को मेमोरी में कंटेनर में कॉपी कर सकते हैं। जावा में, byte[20] अतिरिक्त 16 बाइट्स की मेमोरी खर्च होगी, और उन तक पहुंच लंबी होगी क्योंकि ये बाइट्स कंटेनर से मेमोरी के एक अलग क्षेत्र में हैं। हम byte[20] से पांच इन्टस में परिवर्तित करके इसे प्राप्त करने का प्रयास करते हैं, लेकिन इसमें अतिरिक्त मशीन निर्देशों का खर्च होता है।

C में Git यह सुनिश्चित करने के लिए लेता है कि memcpy(a, b, 20) ऑपरेशन एक फुलाए हुए वृक्ष से स्मृति की सामग्री को संरचना वस्तु में कॉपी करते समय बेहद सस्ता है। JGit को इन 20 बाइट्स को पाँच ints में कॉपी करने के लिए भारी जुर्माना देना पड़ता है, क्योंकि बाद में ये पाँच ints सस्ते होते हैं।

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

जावा-देशी संग्रह (संग्रह प्रकार) हमारे लिए JGit में एक वास्तविक जाल बन गए हैं। हमने java.util.* उपयोग किया java.util.* सुविधाजनक मामलों में प्रकार, और डेटा संरचना के साथ समस्या को लगभग हल करने के लिए लग रहा था, लेकिन वे आमतौर पर एक विशेष डेटा संरचना लिखने की तुलना में बहुत खराब काम करते थे।

उदाहरण के लिए, हमारे पास Map<ObjectId,Object> जैसा दिखना चाहिए, उसके लिए एक ObjectIdSubclassMap था। केवल उन्होंने मांग की कि ऑब्जेक्ट का प्रकार, जिसे आप "मान" के रूप में उपयोग करते हैं, ऑब्जेक्टआईड से आते हैं, क्योंकि ऑब्जेक्ट का यह प्रतिनिधित्व एक कुंजी और मूल्य के रूप में दोनों काम करता है। जब HashMap<ObjectId,Object> पर उपयोग किया जाता है तो यह एक वास्तविक बुरा सपना होता है। (यदि किसी को पता नहीं है, तो ObjectId SHG-1 के लिए JGit का unsigned char[20] )।

कुछ ही दिनों पहले, मैंने एक पैक फ़ाइल में इंडेक्स द्वारा हैशिंग ऑब्जेक्ट्स के लिए, LongMap , LongMap HashMap<Long,Object> का तेज़ संस्करण लिखा था। यहाँ एक ही बात, एक long (सबसे बड़े पूर्णांक) को जावा में पैकेजिंग की लागत मानक हैशपॉप प्रकार के लिए उपयुक्त वस्तु में परिवर्तित करने के लिए काफी अधिक थी।

और अब JGit अभी भी धीमी है जब यह एक प्रतिबद्ध या पेड़ वस्तु को संभालने के लिए आता है, जहां आपको ऑब्जेक्ट लिंक की निगरानी करने की आवश्यकता होती है। या जब inflate() जाता inflate() कहा जाता है। हम इन प्रक्रियाओं पर C में git की तुलना में अधिक समय व्यतीत करते हैं, हालाँकि हम सबसे निचले स्तर पर नीचे जाने की कोशिश करते हैं, क्योंकि byte[] आम तौर पर, किसी भी चीज़ की नकल करने और जब भी संभव हो मेमोरी आवंटन से बचने की अनुमति देता है।

आमतौर पर, JGit rev-list --objects –all बारे में दो बार करता है जब तक Git लिनक्स कर्नेल जैसे प्रोजेक्ट पर करता है, और लगभग 270 एमबी की फ़ाइल के लिए index-pack भी लगभग दो बार लंबे समय तक रहता है।

JGit के दोनों भाग उतने ही अच्छे हैं जितना मुझे उन्हें अनुकूलित करने का ज्ञान है, लेकिन हम वास्तव में JIT की दया पर हैं, और JIT में किसी भी परिवर्तन से हमारे प्रदर्शन में गिरावट (या सुधार) हो सकती है। G में C के विपरीत, जहां Linus Torvalds कोड के पूरे टुकड़ों को कोडांतरक में बदल सकता है और विभिन्न तरीकों की कोशिश कर सकता है।

तो हाँ, उच्च-स्तरीय भाषा में Git बनाने के लिए व्यावहारिक अर्थ है, लेकिन आप अभी तक G में C. Git के समान प्रदर्शन या सख्त मेमोरी खपत प्राप्त करने में सक्षम नहीं हैं। यही कारण है कि एक उच्च-स्तरीय भाषा का सार आपकी लागत है। हालाँकि, JGit काफी ठीक काम करता है; हमारे लिए Google के अंदर git सर्वर के रूप में उपयोग करने के लिए पर्याप्त उपवास है।

पीएस सीन पियर्स की पोस्ट 2009 में लिखी गई थी और लेखक जावा 1.7 में किए गए परिवर्तनों को ध्यान में नहीं रखता है। उदाहरण के लिए, जावा अब जब भी संभव हो, ढेर पर मेमोरी आवंटित करने से बचने के लिए एस्केप एनालिसिस का उपयोग करता है।