कैसे एक iPhone में एक लाख सितारों को फिट करने के लिए

ऐसी रोमांटिक चीज, जैसे तारों वाला आकाश, और ऐसी कट्टर चीज, जैसे iOS एप्लिकेशन की मेमोरी खपत का अनुकूलन, अच्छी तरह से एक साथ जा सकती है: यह इस तारों वाले आकाश को एआर एप्लिकेशन में ढालने की कोशिश करने के लायक है, और इस बारे में सवाल यह है कि बहुत खपत तुरंत उत्पन्न होगी।

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

पोस्ट मोबिअस 2018 पाइटर सम्मेलन से कॉनरोड फाइलर की रिपोर्ट के एक प्रतिलेख के आधार पर तैयार किया गया था। हम इसका वीडियो संलग्न करते हैं, और फिर पहले व्यक्ति में एक पाठ संस्करण:



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

अनुकूलन क्यों?

क्या आम तौर पर हमें अनुकूलन करने के लिए प्रोत्साहित करता है, हम वास्तव में क्या हासिल करना चाहेंगे? हम यह नहीं चाहते:



हम नहीं चाहते कि उपयोगकर्ता प्रतीक्षा करे। यही है, पहला कारण बूट समय को कम करना है ।

एक और कारण गुणवत्ता में सुधार है ।



हम छवियों, ध्वनि और यहां तक ​​कि AI की गुणवत्ता के बारे में बात कर सकते हैं। "अनुकूलित AI" का अर्थ है कि आप अधिक प्राप्त कर सकते हैं - उदाहरण के लिए, आगे बढ़ने के लिए अधिक से अधिक संख्या के लिए खेल की गणना करें।

तीसरा कारण बहुत महत्वपूर्ण है: बैटरी की बिजली की बचत । अनुकूलन बैटरी को कम करने में मदद करता है। यहां एक दिलचस्प तुलना है, Android दुनिया से यद्यपि। यहां वुलकन और ओपनजीएल ईएस की तुलना की गई:



दूसरा मोबाइल प्लेटफ़ॉर्म के लिए बेहतर रूप से अनुकूलित है। बैटरी बिजली की खपत की गति को देखते हुए, आप देख सकते हैं कि इसी तरह की छवि के लिए, ओपनजीएल ईएस ने वल्कन की तुलना में बहुत अधिक संसाधन खर्च किए।

यहां किस तरह का अनुकूलन मदद कर सकता है? उदाहरण के लिए, एक टर्न-आधारित गेम में, जब उपयोगकर्ता अपनी चाल के बारे में सोचता है, तो आप एफपीएस को शून्य तक कम कर सकते हैं। यदि आपके पास एक 3D इंजन है, तो यह पूरी तरह से बुद्धिमान है कि सब कुछ बंद कर दें, जबकि उपयोगकर्ता सिर्फ स्क्रीन को देखता है।

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

कोई कट्टरता नहीं

अनुकूलन के बारे में बोलते हुए, कोई भी डोनाल्ड नथ की थीसिस को याद नहीं कर सकता है: "हमें कम दक्षता के बारे में भूलना चाहिए, 97% मामलों में कहते हैं: समय से पहले अनुकूलन सभी बुराइयों की जड़ है। हालांकि हमें इन महत्वपूर्ण 3% में अपनी क्षमताओं को नहीं छोड़ना चाहिए। ”

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

सामान्य तौर पर, आवश्यकतानुसार प्राथमिकता और अनुकूलन।

दृष्टिकोण

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

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

आईओएस डेवलपर्स के लिए, एक्सकोड इंस्ट्रूमेंट्स में एक टाइम प्रोइलर टूल है। यह आपको अपने आवेदन के विभिन्न हिस्सों द्वारा खर्च किए गए सीपीयू चक्रों की संख्या को ट्रैक करने की अनुमति देता है। यह रिपोर्ट टूल के बारे में नहीं है, इसलिए मैं अब विवरण में नहीं गया, इस बारे में WWDC का एक अच्छा वीडियो था।

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

यह भी महत्वपूर्ण है कि विभिन्न उपकरणों के लिए रैम संसाधन भी अलग है। यदि आप कहते हैं, ऐप्पल वॉच के लिए विकसित करने का निर्णय लिया गया है, तो पर्याप्त मेमोरी नहीं है, और यह आपको अनुकूलन भी बनाता है।

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



Element8 में 8 बाइट्स शामिल हैं, Element16 - 16, और इसी तरह।



हम प्रत्येक प्रकार की संरचनाओं के लिए, सरणियाँ बनाएंगे। सभी सरणियों का आयाम समान है - 10,000 तत्व। प्रत्येक संरचना में अलग-अलग फ़ील्ड्स (बढ़ती) होती हैं; फ़ील्ड n पहला फ़ील्ड है और, तदनुसार, सभी संरचनाओं में मौजूद है।

अब चलो निम्नलिखित प्रयास करें: प्रत्येक सरणी के लिए हम इसके सभी क्षेत्रों की राशि की गणना करेंगे n। यही है, हर बार हम समान तत्वों (10,000 टुकड़े) की राशि का योग करेंगे। एकमात्र अंतर यह है कि प्रत्येक राशि के लिए चर n को विभिन्न आकारों की संरचनाओं से निकाला जाएगा। हम इस बात में रुचि रखते हैं कि क्या समान समय लगता है।

परिणाम निम्नलिखित है:



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

प्रोसेसर में L1, L2 कैश (कभी-कभी L3 और L4) भी होते हैं। प्रोसेसर इस प्रकार की मेमोरी को सीधे और जल्दी से एक्सेस करता है।



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



L1, L2 कैश के आकार इतने बड़े नहीं हैं। प्रोसेसर द्वारा काम करने के लिए आवश्यक सरणी बड़ी हो सकती है। इस तरह के एक सरणी पर पूरी तरह से ऑपरेशन करने के लिए, हमें इसे भागों में कैश में अनलोड करना होगा और एक-एक करके इन हिस्सों पर काम करना होगा। मुख्य मेमोरी में लगातार अनुरोधों के कारण, हमारे सरणी को संसाधित करने में अधिक समय लगेगा।

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

CPU बनाम RAM: आलसी इनिशियलाइज़ेशन

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

मान लीजिए कि हमारे पास एक मेक हाइवेऑबजेक्ट () विधि है जो किसी बड़ी वस्तु को लौटाती है। यह विधि lazilyCalculated चर को इनिशियलाइज़ करेगी।



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

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

आप दूसरे तरीके से जा सकते हैं - फील्ड वैल्यू को बिल्कुल स्टोर न करें:



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

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

अनुकूलन चक्र

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

एक वस्तु का चयन करते हुए, आप अपने आप को कार्य निर्धारित करते हैं (या वैज्ञानिक रूप से बोलते हुए, एक परिकल्पना को आगे बढ़ाते हैं): कुछ अनुकूलन विधियों को लागू करके, आप चयनित कोड के काम को तेजी से कर सकते हैं।

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

जैसे एक वैज्ञानिक कार्य में: अटकलें, प्रयोग, परिणामों का विश्लेषण। आप बार-बार क्रियाओं के इस चक्र से गुजरते हैं। अभ्यास से पता चलता है कि इस तरह से बनाया गया काम वास्तव में आपको एक-एक करके बॉटनेक्स को खत्म करने की अनुमति देता है।

यूनिट परीक्षण

यूनिट परीक्षणों के बारे में संक्षेप में: हमारे पास कुछ फ़ंक्शन हैं जो हम परीक्षण कर रहे हैं, कुछ इनपुट डेटा इनपुट और आउटपुट डेटा आउटपुट; इनपुट के रूप में इनपुट प्राप्त करना, हमारे फ़ंक्शन को हमेशा आउटपुट वापस करना चाहिए, और हमारे किसी भी अनुकूलन को इस संपत्ति का उल्लंघन नहीं करना चाहिए।

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

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

और अब मज़ेदार हिस्से के लिए, चलो सितारों पर चलते हैं।

मिलियन स्टार्स

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



शहर की रोशनी की अनुपस्थिति में, एक व्यक्ति आकाश में 8,000 सितारों तक को भेद सकता है। मुझे 8,000 रिकॉर्ड स्टोर करने के लिए लगभग 1.8 एमबी की आवश्यकता होगी। सिद्धांत रूप में, स्वीकार्य है। लेकिन मैं उन सितारों को जोड़ना चाहता था जो एक व्यक्ति टेलीस्कोप के माध्यम से देख सकता है - यह लगभग 120,000 सितारों (तथाकथित हिप्पोर्कस कैटलॉग के अनुसार, अब अप्रचलित है) निकला। इसके लिए पहले से ही 27 एमबी की आवश्यकता थी। और सार्वजनिक क्षेत्र में आधुनिक कैटलॉग के बीच आप एक पा सकते हैं जो लगभग 2,500,000 सितारों की संख्या होगी। ऐसा डेटाबेस पहले से ही लगभग 560 एमबी का होगा। जैसा कि आप देख सकते हैं, बहुत सारी मेमोरी पहले से ही आवश्यक है। लेकिन हम केवल एक डेटाबेस नहीं चाहते हैं, लेकिन इसके आधार पर एक एप्लिकेशन, जहां ARKit, SceneKit और अन्य चीजें होंगी जो मेमोरी की आवश्यकता होती हैं।

क्या करें?
हम तारों का अनुकूलन करेंगे।

MemoryLayout टूल

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

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



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



StarData, हमारी प्रायोगिक संरचना, इसकी प्रारंभिक स्थिति में:



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

हम कठोर संपत्ति का अनुरोध करते हैं:



फिलहाल, हमारी संरचना का वजन 208 बाइट्स है। एक लाख ऐसी संरचनाओं के लिए 250 एमबी की आवश्यकता होगी - यह, जैसा कि आप जानते हैं, बहुत अधिक है। इसलिए, अनुकूलन करना आवश्यक है।

सही इंट

तथ्य यह है कि पहले प्रोग्रामिंग पाठों में इंट की विभिन्न किस्में बताई गई हैं। स्विफ्ट में हमारे लिए सबसे परिचित Int को Int8 कहा जाता है। यह 8 बिट्स (1 बाइट) पर कब्जा कर लेता है और -128 से 127 समावेशी मूल्यों को स्टोर कर सकता है। अन्य Ints भी हैं:

• 2 बाइट्स के आकार में Int16, मूल्यों की सीमा -32,768 से 32,767 तक है;
• 4 बाइट्स के आकार में Int32, मानों की सीमा -2,147,483,648 से 2,147,483,647 है;
• Int64 (या सिर्फ Int) आकार में 8 बाइट्स है, मानों की सीमा -9,223,372,036,854,775,808 से 9,223,372,036,854,775,807 है।

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

आइए देखें, उदाहरण के लिए, आईडी वाले फ़ील्ड पर। हम जानते हैं कि हमारे पास एक लाख सितारे होंगे - कुछ दसियों हजार नहीं, बल्कि एक अरब नहीं। तो, ऐसे क्षेत्रों के लिए, Int32 चुनना सबसे अच्छा है। तब मुझे महसूस हुआ कि फ्लोट के लिए यहां 4 बाइट्स पर्याप्त हैं। डबल 8 पर कब्जा कर लेगा, प्रत्येक 24 को स्ट्रिंग करेगा, इसे सभी जोड़ देगा - यह 152 बाइट्स निकलता है। अगर आपको याद है, तो पहले मैमोरी लोटआउट ने हमें बताया था कि 208. क्यों? हमें गहरी खुदाई करनी चाहिए।



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

हम एक चर पर एक अतिरिक्त बाइट खर्च नहीं करना चाहते हैं। उसी समय, हम वास्तव में वैकल्पिक रूप में सन्निहित विचार को पसंद करते हैं। किसके साथ आना है? आइए हमारी संरचना को लागू करने का प्रयास करें।

घोषित मूल्य के लिए उपयुक्त होने पर, कुछ ऐसे मान का चयन करें जिन्हें किसी दिए गए क्षेत्र के लिए "अमान्य" माना जा सकता है। GetHipId (Int32) के लिए यह हो सकता है, उदाहरण के लिए, मूल्य "-1"। इसका अर्थ होगा कि हमारा क्षेत्र आरंभिक नहीं है। यहां ऐसी साइकिल वैकल्पिक है, जो बिना किसी अतिरिक्त बाइट के नील पर चलती है।

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



इस तरह के एक गटर पूरी तरह से एक आविष्कार समाधान की जटिलता से हमें रोकते हैं।
हमारे StarData की ओर मुड़ें। सभी वैकल्पिक प्रकारों को नियमित लोगों के साथ बदलें और देखें कि स्ट्राइड क्या दिखाता है:


यह पता चला है कि विकल्पों को समाप्त करने से, हमने 9 बाइट्स (नौ विकल्पों में से प्रत्येक के लिए एक बाइट) को बचाया, लेकिन 48 के रूप में कई। आश्चर्य सुखद है, लेकिन मैं जानना चाहूंगा कि ऐसा क्यों हुआ। और यह मेमोरी में डेटा के संरेखण के कारण हुआ।

डेटा संरेखण

स्मरण करो कि स्विफ्ट से पहले हमने ऑब्जेक्टिव-सी में लिखा था, और यह सी पर आधारित था - और यह स्थिति भी सी पर वापस जाती है।

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

• प्रकार चार का एक चर 1, 2, 3, 4, आदि से शुरू हो सकता है। बाइट्स, क्योंकि यह अपने आप में केवल एक बाइट लेता है;
• एक छोटा चर 2 बाइट्स लेता है, इसलिए यह 2 वें, 4 वें, 6 वें, 8 वें आदि से शुरू हो सकता है। एक बाइट (यानी, प्रत्येक बाइट से भी);
• प्रकार फ्लोट का एक चर 4 बाइट्स लेता है, जिसका अर्थ है कि यह हर 4 वें, 8 वें, 12 वें, 16 वें, आदि से शुरू हो सकता है। एक बाइट (यानी, हर चौथे बाइट);
• डबल और स्ट्रिंग प्रकार के चर प्रत्येक 8 बाइट्स पर कब्जा करते हैं, इसलिए वे 8 वें, 16 वें, 24 वें, 32 वें, आदि से शुरू हो सकते हैं। बाइट्स;
• आदि

MemoryLayout <> ऑब्जेक्ट्स में एक संरेखण गुण होता है जो निर्दिष्ट प्रकार के लिए संबंधित संरेखण नियम देता है।

क्या हम कोड को अनुकूलित करने के लिए संरेखण नियमों का ज्ञान लागू कर सकते हैं? आइए एक उदाहरण देखें। एक उपयोगकर्ता संरचना है: FirstName और lastName के लिए हम एक नियमित स्ट्रिंग का उपयोग करते हैं, मध्यनाम के लिए - एक वैकल्पिक स्ट्रिंग (उपयोगकर्ता का ऐसा नाम नहीं हो सकता है)। स्मृति में, इस तरह की संरचना का एक उदाहरण इस प्रकार रखा जाएगा:



जैसा कि आप देख सकते हैं, चूंकि वैकल्पिक मध्यनाम 25 बाइट्स लेता है (8 24 बाइट्स के गुणकों के बजाय), संरेखण नियम आपको अगले 7 बाइट्स को छोड़ने और संपूर्ण संरचना पर 80 बाइट्स खर्च करने के लिए बाध्य करते हैं। यहां, कोई फर्क नहीं पड़ता कि आप स्ट्रिंग्स के साथ ब्लॉक कैसे करते हैं, यह बाइट्स की एक छोटी संख्या पर भरोसा करना असंभव है।

और अब असफल संरेखण का एक उदाहरण:



BadAligned संरचना पहले घोषित करती है कि टाइप बूल (1 बाइट), तब टाइप डबल (8 बाइट्स) का आकार, प्रकार बूल (1 बाइट) का निष्क्रिय और अंत में टाइप इंट (8 बाइट्स) की आयु से अलग है। इस क्रम में घोषित, हमारे चरों को स्मृति में इस तरह रखा जाएगा कि कुल संरचना 32 बाइट पर कब्जा कर लेगी।

आइए खेतों को घोषित करने के क्रम को बदलने की कोशिश करें - हम उन्हें कब्जे वाले वॉल्यूम के आरोही क्रम में व्यवस्थित करेंगे और देखें कि स्मृति में तस्वीर कैसे बदलती है।



हमारी संरचना 32 बाइट्स नहीं लेती है, लेकिन 24. 25% बचाएं।

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

चलिए फिर से अपने स्टारडॉट की ओर मुड़ते हैं। आइए, कब्जे की मात्रा बढ़ाने के क्रम में इसके खेतों को व्यवस्थित करने का प्रयास करें।



पहले, फ्लोट और इंट 32, फिर डबल और स्ट्रिंग। नहीं है कि जटिल Tetris!
हमें जो स्ट्राइड मिला है वह 152 बाइट्स का है। यही है, विकल्पों के कार्यान्वयन का अनुकूलन करके और संरेखण के साथ काम करके, हम संरचना के आकार को 208 से 152 बाइट्स तक कम करने में सक्षम थे।

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

डोमेन लॉजिक अकाउंटिंग

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

एक बार फिर से StarData पर नज़र डालें। हमारे स्पष्ट "अड़चन" स्ट्रिंग के प्रकार हैं, वे वास्तव में बहुत अधिक स्थान लेते हैं। और यहाँ बारीकियाँ इस प्रकार हैं: रनटाइम के दौरान, इनमें से अधिकांश लाइनें खाली रहती हैं! केवल 146 सितारों का एक "वास्तविक" नाम है, जिसे उचित नाम फ़ील्ड में इंगित किया गया है। और gl_id Gliese कैटलॉग के अनुसार स्टार की आईडी है, जिसमें 3801 सितारे हैं, वह भी एक मिलियन से दूर है। bayer_flamstedt - फ्लेमस्टेड के पदनाम - 3064 वें सितारों को सौंपा जाएगा। वर्णक्रमीय प्रकार स्पेक्ट्रल टाइप 4307 मील है। यह पता चला है कि अधिकांश सितारों के लिए, दर्ज किए गए स्ट्रिंग चर खाली होंगे, जबकि प्रत्येक पर 24 बाइट्स होंगे।

मैं निम्नलिखित तरीके से बाहर आया। आइए एक अतिरिक्त संरचना के रूप में एक सहयोगी सरणी प्राप्त करें। एक कुंजी के रूप में - Int16 प्रकार का एक विशिष्ट संख्यात्मक पहचानकर्ता, मूल्य के रूप में, विशेषता स्ट्रिंग की उपस्थिति पर निर्भर करता है - या तो इसका मूल्य या -1।

हमारे StarData में ProperName, gl_id, bayer_flamstedt और स्पेक्ट्रल टाइप के विपरीत हम सरणी में कुंजी के अनुरूप इंडेक्स लिखेंगे। यदि आवश्यक हो, तो एक या अन्य विशेषता स्ट्रिंग प्राप्त करें, हम सूचकांक के माध्यम से सरणी से मूल्य का अनुरोध करेंगे। इसे मैन्युअल रूप से करने की कोई आवश्यकता नहीं है - हम बेहतर सुविधाजनक गेटर को लागू करते हैं:



गेट्टर यहां बहुत महत्वपूर्ण है - यह हमारे स्वयं के कार्यान्वयन की जटिलता को हमसे छिपाता है। एक सरणी को निजी के रूप में पंजीकृत किया जा सकता है, अब इसके अस्तित्व के बारे में जानना आवश्यक नहीं है।

बेशक, इस समाधान में एक माइनस है। मेमोरी को सेव करना प्रोसेसर लोड को प्रभावित नहीं कर सकता है। इस योजना के साथ, हम अपने सहयोगी सरणी को लगातार एक्सेस करने के लिए मजबूर हैं; और ज्यादातर मामलों में - व्यर्थ में, चूंकि अधिकांश लाइनें खाली रहेंगी और अनुरोध "-1" वापस आ जाएंगे।

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

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

कुल: स्ट्राइड अब हमें 64 बाइट्स देता है!

क्या वह सब है? नहीं, अब हमें फिर से संरेखण नियमों के बारे में सोचने की जरूरत है: Int16 के प्रकारों को फिर से व्यवस्थित करें।



अब यह सब है। जैसा कि आप देख सकते हैं, अनिवार्य रूप से सरल तरीकों की एक छोटी संख्या का उपयोग करते हुए, हम स्टारडेटा संरचना के आकार को 208 से 56 बाइट्स तक कम करने में सक्षम थे। एक मिलियन सितारे अब 500 एमबी नहीं, बल्कि 130 पर कब्जा करते हैं। चार गुना कम!

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

कंपाइलर ऑप्टिमाइज़ेशन स्विफ्ट

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

लेकिन निर्माण प्रक्रिया आपको अपने कोड के बारे में कुछ बता सकती है। यह बोटनेकोव का एक उत्कृष्ट संकेतक है, आपको बस इसे काम करने के लिए अनुकूलित करने की आवश्यकता है।

व्यक्तिगत रूप से, मैंने Xcode में संकलन पर शोध किया। एक उपकरण के रूप में, मैंने निम्नलिखित कमांड का उपयोग किया:



यह कमांड xCode को प्रत्येक फ़ंक्शन के संकलन समय को ट्रैक करने और अपराधी के लिए लिखने के लिए निर्देश देता है। पाठ फ़ाइल। फ़ाइल की सामग्री को रास्ते में क्रमबद्ध किया गया है।



अपने सरल उपकरण का उपयोग करके, मैं दिलचस्प चीजों का निरीक्षण कर सकता हूं। कोड की केवल तीन पंक्तियों को सम्‍मिलित करते हुए कुछ विधियों को 2 सेकंड तक संकलित किया जा सकता है। क्या कारण हो सकता है?

उदाहरण के लिए, टाइप कंपाइलर आउटपुट जैसी चीज। यदि आप स्पष्ट रूप से प्रकारों को निर्दिष्ट नहीं करते हैं, तो स्विफ्ट को स्वयं का पता लगाने के लिए मजबूर किया जाता है। यह (मुझे कहना चाहिए, गैर-तुच्छ) ऑपरेशन के लिए प्रोसेसर समय की आवश्यकता होती है, इसलिए, संकलक के दृष्टिकोण से, प्रकार को इंगित करना हमेशा बेहतर होता है। बस स्पष्ट रूप से प्रकारों को लिखकर, मैं एक बार एप्लिकेशन के बिल्ड समय को 5 से 2 (!) मिनट तक कम करने में सक्षम था।

लेकिन एक "लेकिन" है: बिना प्रकार के कोड अभी भी अधिक पठनीय है। और हम पहले से ही प्राथमिकताओं के बारे में बात कर चुके हैं। समय से पहले अनुकूलन न करें: पहली बार में, कोड की पठनीयता अधिक महंगी होगी।

सर्वर का विकल्प

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

संक्षेप में कहना

अंत में, मुख्य विचारों का एक संक्षिप्त सारांश जिसे मैं आज आपको संबोधित करना चाहता था:

• . . , , , ?
• , unit-. , unit-. , . Unit- , .
• . , . , : — .
• अपने एप्लिकेशन के डोमेन तर्क के साथ काम करें। सबसे शक्तिशाली अनुकूलन उपकरण डोमेन लॉजिक के साथ कुशल काम है। काम की विशेषताओं को जानें, आपके आवेदन की बारीकियों - उन्हें ध्यान में रखने की कोशिश करें, अपने "व्यक्तिगत" समाधानों की तलाश करें।
• RAM बनाम सीपीयू। मेमोरी और प्रोसेसर के उपयोग के संतुलन को बनाए रखने की पूरी कोशिश करें। यह हमेशा बहुत मुश्किल होता है, लेकिन प्रत्येक विशेष मामले में एक निश्चित इष्टतम खोजना अभी भी संभव है।

यदि आप मोबियस सम्मेलन की इस रिपोर्ट को पसंद करते हैं, तो कृपया ध्यान दें कि मोबियस 2018 मास्को 8-9 दिसंबर को आयोजित किया जाएगा , जहां बहुत सारी दिलचस्प चीजें भी होंगी। 1 नवंबर से, टिकट की कीमतें बढ़ रही हैं, इसलिए यह निर्णय लेने के लिए समझ में आता है!