वृद्धिशील एनोटेशन गति में तेजी को बढ़ाता है

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

वृद्धिशील संकलन कैसे काम करता है

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

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

ऐप मॉड्यूल का मुख्य वर्ग ( कोर पर निर्भर करता है):

public class Main { public static void main(String... args) { WordCount wc = new WordCount(); wc.collect(new File(args[0]); System.out.println("Word count: " + wc.wordCount()); } } 

कोर मॉड्यूल में ( बर्तनों पर निर्भर करता है):

 public class WordCount { // ... void collect(File source) { IOUtils.eachLine(source, WordCount::collectLine); } } 

बर्तन मॉड्यूल में:

 public class IOUtils { void eachLine(File file, Callable<String> action) { try { try (BufferedReader reader = new BufferedReader(new FileReader(file))) { // ... } } catch (IOException e) { // ... } } } 

मॉड्यूल के पहले संकलन का क्रम निम्नानुसार है (निर्भरता के क्रम के अनुसार):

1) बर्तन
2) कोर
3) ऐप

अब विचार करें कि जब आप IOUtils वर्ग के आंतरिक कार्यान्वयन को बदलते हैं तो क्या होता है:

 public class IOUtils { // IOUtils lives in project `utils` void eachLine(File file, Callable<String> action) { try { try (BufferedReader reader = new BufferedReader(new InputStreamReader(new FileInputStream(file), "utf-8") )) { // ... } } catch (IOException e) { // ... } } } 

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

परियोजना मॉड्यूल स्तर पर संकलन परिहार का चित्रण

व्यक्तिगत मॉड्यूल के अंदर सीधे परिवर्तित फ़ाइलों के लिए संकलक लॉन्च स्तर पर वेतन वृद्धि का दूसरा स्तर है।

उदाहरण के लिए, कोर मॉड्यूल में एक नया वर्ग जोड़ें:

 public class NGrams { // NGrams lives in project `core` // ... void collect(String source, int ngramLength) { collectInternal(StringUtils.sanitize(source), ngramLength); } // ... } 

और बर्तन में :

 public class StringUtils { static String sanitize(String dirtyString) { ... } } 

इस मामले में, दोनों मॉड्यूल में केवल दो नई फाइलों को फिर से जमा करना आवश्यक है (मौजूदा और प्रभावित हुए WordCount और IOUtils को प्रभावित किए बिना), क्योंकि नए और पुराने वर्गों के बीच कोई निर्भरता नहीं है।

इस प्रकार, वृद्धिशील संकलक केवल कक्षाओं और रीकॉम्पिल के बीच निर्भरता का विश्लेषण करता है:

• परिवर्तन वाली कक्षाएं

• कक्षाएं जो सीधे बदलती कक्षाओं पर निर्भर करती हैं

  
  

  वृद्धिशील एनोटेशन प्रसंस्करण

  
  

  

  
  

एपीटी और केएपीटी का उपयोग करके कोड बनाने से बायलरप्लेट कोड को लिखने और डिबग करने में लगने वाले समय में कमी आती है, लेकिन एनोटेशन प्रोसेसिंग में बिल्ड टाइम में काफी वृद्धि हो सकती है। मामलों को बदतर बनाने के लिए, लंबे समय तक, एनोटेशन प्रसंस्करण ने मौलिक रूप से ग्रैडल में वृद्धिशील संकलन की संभावनाओं को तोड़ दिया।

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

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

एनोटेशन प्रोसेसर श्रेणियाँ

ग्रेडल प्रोसेसर की दो श्रेणियों का समर्थन करता है:

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

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

कोड पीढ़ी के आधार पर कई लोकप्रिय पुस्तकालयों के लिए, नवीनतम संस्करणों में वृद्धिशील संकलन समर्थन पहले से ही लागू है। उन पुस्तकालयों की सूची देखें जो इसका समर्थन करते हैं ।

वृद्धिशील एनोटेशन प्रसंस्करण को लागू करने का हमारा अनुभव

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

इसलिए, काम करने के लिए एनोटेशन के वृद्धिशील प्रसंस्करण के लिए, हमें आवश्यकता है:

• ग्रेडल 4.7+
• कोटलिन 1.3.30+
• हमारी परियोजना में सभी एनोटेशन प्रोसेसर के पास इसका समर्थन होना चाहिए। यह बहुत महत्वपूर्ण है, क्योंकि यदि किसी एकल मॉड्यूल में कम से कम एक प्रोसेसर वेतन वृद्धि का समर्थन नहीं करता है, तो ग्रेडल इसे पूरे मॉड्यूल के लिए अक्षम कर देगा। मॉड्यूल में सभी फ़ाइलों को हर बार फिर से संकलित किया जाएगा! संस्करणों को अपग्रेड किए बिना वृद्धिशील संकलन के लिए समर्थन प्राप्त करने के लिए वैकल्पिक विकल्पों में से एक एक अलग मॉड्यूल में एनोटेशन प्रोसेसर का उपयोग करके सभी कोड को हटाना है। ऐसे मॉड्यूल जिनमें एनोटेशन प्रोसेसर नहीं हैं, वृद्धिशील संकलन ठीक काम करेगा

अंतिम स्थिति को संतुष्ट नहीं करने वाले प्रोसेसर का पता लगाने के लिए, आप फ्लैग के साथ असेंबली चला सकते हैं -kapt.verbose = true । यदि ग्रैडल को एकल मॉड्यूल के लिए वृद्धिशील एनोटेशन प्रसंस्करण को अक्षम करने के लिए मजबूर किया गया था, तो बिल्ड लॉग में हम एक संदेश देखेंगे कि कौन से प्रोसेसर और किस मॉड्यूल में ऐसा हो रहा है (कार्य का नाम देखें):

 > Task :common:kaptDebugKotlin w: [kapt] Incremental annotation processing requested, but support is disabled because the following processors are not incremental: toothpick.compiler.factory.FactoryProcessor (NON_INCREMENTAL), toothpick.compiler.memberinjector.MemberInjectorProcessor (NON_INCREMENTAL). 

गैर-वृद्धिशील एनोटेशन प्रोसेसर के साथ हमारी लाइब्रेरी परियोजना पर, 3 थे:

• दंर्तखोदनी
• कक्ष
• PermissionsDispatcher

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

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

Kotlin 1.3.30-1.3.50 के संस्करणों के लिए, आपको प्रोजेक्ट के gradle.properties फ़ाइल में kapt.incremental.apt = true के माध्यम से एनोटेशन के वृद्धिशील प्रसंस्करण के लिए समर्थन सक्षम करना होगा। संस्करण 1.3.50 के साथ शुरू, यह विकल्प डिफ़ॉल्ट रूप से सही पर सेट है।

वृद्धिशील विधानसभा रूपरेखा

सभी आवश्यक निर्भरता के संस्करणों को उठाए जाने के बाद, वृद्धिशील बिल्ड की गति का परीक्षण करने का समय है। ऐसा करने के लिए, हमने उपकरण और तकनीकों के निम्नलिखित सेट का उपयोग किया:

• ग्रैड बिल्ड स्कैन
• Gradle-प्रोफाइलर
• सक्षम और अक्षम वृद्धिशील एनोटेशन प्रसंस्करण के साथ स्क्रिप्ट चलाने के लिए, gradle गुण kapt.incremental. = = [सत्य | गलत] का उपयोग किया गया था।
• सुसंगत और सूचनात्मक परिणामों के लिए, विधानसभाओं को एक अलग सीआई वातावरण में उठाया गया था। वृद्धिशीलता का उपयोग कर ग्रेडेल-प्रोफाइलर का उपयोग किया गया

gradle-profiler वृद्धिशील बिल्ड मानदंड के लिए घोषित रूप से स्क्रिप्ट तैयार करने की अनुमति देता है। 4 स्थितियों को निम्नलिखित स्थितियों के आधार पर संकलित किया गया था:

• किसी फ़ाइल को संशोधित करना उसके ABI को प्रभावित / प्रभावित नहीं करता है
• वृद्धिशील एनोटेशन प्रसंस्करण पर / बंद के लिए समर्थन

प्रत्येक परिदृश्य में रन का एक क्रम है:

• ग्रेडेल डेमॉन को फिर से शुरू करना
• लॉन्च वार्म-अप बिल्ड
• 10 वृद्धिशील असेंबली चलाएं, जिनमें से प्रत्येक से पहले एक नई विधि जोड़कर एक फ़ाइल को बदल दिया जाता है (गैर-एबीआई परिवर्तनों के लिए निजी और एबीआई परिवर्तनों के लिए सार्वजनिक)

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

यह भी ध्यान देने योग्य है कि बेंचमार्क रन को दो ग्रेडल कार्यों पर किया गया था: ompileDebugSources और assembleDebug । पहले केवल स्रोत कोड के साथ फ़ाइलों का संकलन शुरू होता है, बिना संसाधनों के साथ काम करने और एप्लिकेशन को एक .apk फ़ाइल में बंडल करने के बिना। इस तथ्य के आधार पर कि वृद्धिशील संकलन केवल .kt और .java फ़ाइलों को प्रभावित करता है, compileDedugSource कार्य को अधिक पृथक और तेज़ बेंचमार्किंग के लिए चुना गया था। वास्तविक विकास की स्थितियों में, जब आप एप्लिकेशन को पुनः आरंभ करते हैं, तो एंड्रॉइड स्टूडियो असेंबडबग कार्य का उपयोग करता है, जिसमें एप्लिकेशन के डिबग संस्करण की पूरी पीढ़ी शामिल होती है।

बेंचमार्क परिणाम

ग्रेडल-प्रोफाइलर द्वारा उत्पन्न सभी ग्राफों में, ऊर्ध्वाधर अक्ष मिलीसेकंड में वृद्धिशील विधानसभा समय दिखाता है, और क्षैतिज अक्ष विधानसभा प्रारंभ संख्या दिखाता है।

: एनोटेशन प्रोसेसर को अपडेट करने से पहले compileDebugSource

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

: annileation प्रोसेसर अपडेट करने के बाद compileDebugSource

असमानता के कारण विधानसभा समय में औसतन कमी ABI परिवर्तनों के लिए 31% और गैर-ABI परिवर्तनों के लिए 32.5% थी। निरपेक्ष मूल्य में, लगभग 10 सेकंड।

: एनबेशन ​​प्रोसेसर्स को अपडेट करने के बाद असेंबल्ड डीबग करें

हमारी परियोजना पर आवेदन के पूर्ण डिबग संस्करण का निर्माण करने के लिए, वेतन वृद्धि के कारण निर्माण समय में औसतन 21.5% ABI परिवर्तन के लिए और 23% गैर-ABI परिवर्तनों के लिए था। निरपेक्ष रूप से, लगभग 10 सेकंड, क्योंकि स्रोत कोड के संकलन में वृद्धि से संसाधनों की विधानसभा की गति प्रभावित नहीं होती है।

ग्रैड बिल्ड स्कैन में स्कैन एनाटॉमी बनाएँ

वृद्धिशील संकलन के दौरान वेतन वृद्धि कैसे हुई, इसकी गहरी समझ के लिए, हम वृद्धिशील और गैर-वृद्धिशील असेंबली के स्कैन की तुलना करते हैं।

विकलांग KAPT वेतन वृद्धि के मामले में, बिल्ड टाइम का मुख्य भाग ऐप-मॉड्यूल का संकलन है, जिसे अन्य कार्यों के साथ समानांतर नहीं किया जा सकता है। गैर-वृद्धिशील KAPT के लिए समयरेखा इस प्रकार है:

कार्य निष्पादन: हमारे ऐप-मॉड्यूल के kaptDebugKotlin को इस मामले में लगभग 8 सेकंड लगते हैं।

KAPT वेतन वृद्धि के साथ मामले के लिए समयरेखा सक्षम:

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

उसी समय, प्रसंस्करण एनोटेशन की अक्षम वृद्धिशीलता के लिए सभी * kapt कार्यों का कुल निष्पादन समय 1 मिनट और 55 सेकंड के खिलाफ 36 सेकंड है जब इसे चालू किया जाता है। यही है, मॉड्यूल की समानांतर विधानसभा को ध्यान में रखे बिना, लाभ अधिक पर्याप्त है।

यह भी ध्यान देने योग्य है कि विधानसभा के लिए 24 समानांतर धागे चलाने की क्षमता के साथ सीआई-पर्यावरण पर उपरोक्त बेंचमार्क परिणाम तैयार किए गए थे। 8-थ्रेडेड वातावरण पर, वृद्धिशील एनोटेशन प्रसंस्करण को सक्षम करने से लाभ हमारी परियोजना पर लगभग 20-30 सेकंड है।

वृद्धिशील बनाम (?) समानांतर

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

परिणाम

• हमारी परियोजना पर एनोटेशन के वृद्धिशील प्रसंस्करण के समावेश ने हमें स्थानीय पुनर्निर्माण की गति में 20% वृद्धि प्राप्त करने की अनुमति दी
• वृद्धिशील एनोटेशन प्रसंस्करण को सक्षम करने के लिए, वर्तमान असेंबली के पूर्ण लॉग का अध्ययन करना और पाठ के साथ चेतावनी संदेशों की तलाश करना उपयोगी होगा "इंक्रीमेंटल एनोटेशन प्रोसेसिंग का अनुरोध किया गया, लेकिन समर्थन अक्षम है क्योंकि निम्नलिखित प्रोसेसर इंक्रीमेंटल नहीं हैं ..."। यह एनोटेशन के वृद्धिशील प्रसंस्करण के लिए समर्थन के साथ पुस्तकालयों के संस्करणों को उन्नत करने के लिए आवश्यक है और संस्करण ग्रेडल 4.7+, कोटलिन 1.3.30+ हैं

सामग्री और विषय पर क्या पढ़ना है

• ग्रेड जावा प्लगइन स्तर पर वृद्धिशील एनोटेशन प्रसंस्करण के लिए समर्थन के बारे में
• ग्रेडल-प्रोफाइलर के बारे में लेख
• अधिक KAPT सुविधाओं पर
• वर्तमान निर्माण त्वरण चाल के साथ Google I / O 2019 पर रिपोर्ट करें
• Google I / O 2017 पर ग्रैड ऑप्टिमाइज़ेशन की एक अन्य रिपोर्ट में वृद्धिशील निर्माण सामग्री और संकलन परिहार शामिल है