IPhone पर विलंबता संख्या

लेटेंसी नंबर हर प्रोग्रामर को पता होना चाहिए - "देरी जो हर प्रोग्रामर को पता होनी चाहिए।" इसमें 2012 में बुनियादी कंप्यूटर संचालन करने के लिए समय के औसत मूल्य शामिल हैं। इस तालिका के लिए कई वैकल्पिक विचार हैं, और यहाँ उनमें से एक है।


स्कीमा स्रोत से लिंक करें

लेकिन 2019 में इस जानकारी के मोबाइल डेवलपर्स के लिए क्या लाभ है? ऐसा लगता है कि नहीं, लेकिन Yandex.Navigator टीम से दिमित्री कुर्किन ( SClown ) ने सोचा: "टेबल एक आधुनिक iPhone के लिए कैसा दिखेगा?" AppsConf पर दिमित्री की रिपोर्ट के एक संशोधित पाठ संस्करण में यह क्या आया था।

यह किस लिए है?

प्रोग्रामर को इन नंबरों को क्यों जानना चाहिए? और क्या वे मोबाइल डेवलपर्स के लिए प्रासंगिक हैं? इन संख्याओं की मदद से दो मुख्य कार्य हल किए जा सकते हैं।

एक कंप्यूटर के टाइम स्केल को समझना

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

लेकिन एक सरणी में एक संख्या को जोड़ने जैसे संचालन के बारे में क्या - बहुत "त्वरित सम्मिलित करें" जो लोग कभी-कभी साक्षात्कार में बात करना पसंद करते हैं? स्मार्टफोन पर कितना लेती है? नैनोसेकंड, माइक्रोसेकंड या मिलीसेकंड? मैं ऐसे कुछ लोगों से मिला हूं जो कह सकते हैं कि 1 मिलीसेकंड एक लंबा समय है, लेकिन हमारे मामले में ऐसा है।

विभिन्न कंप्यूटर घटकों की गति का अनुपात

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

वास्तविक जीवन में "विलंबता संख्या"

जब मैंने इन नंबरों को देखा, तो मुझे कैश और मेमोरी एक्सेस के अंतर में दिलचस्पी हो गई। अगर मैंने सावधानी से अपना डेटा 64 Kbytes में डाला, जो इतना छोटा नहीं है, तो मेरा कोड 100 गुना तेजी से काम करेगा - यह तेज़ है, सब कुछ उड़ जाएगा!



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

बफर का आकार	कुल समय	सर्जरी का समय
50 केबी	1.5 मि	30 एन.एस.
500 केबी	12 एमएस	24 एन.एस.
5000 केबी	85 मि	17 एन.एस.

बफर का आकार 100 गुना बढ़ गया, और ऑपरेशन का समय न केवल 100 गुना बढ़ गया, बल्कि लगभग 2 गुना कम हो गया। सज्जनों, अधिकारियों, उन्होंने हमें धोखा दिया! "

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

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



LMbench ने मुझे इन परिणामों को प्राप्त करने में मदद की। यह लिनक्स कर्नेल के डेवलपर्स में से एक लैरी मैकवॉय द्वारा बनाया गया एक बेंचमार्क है, जो आपको मेमोरी एक्सेस समय, स्विचिंग थ्रेड्स और फाइल सिस्टम ऑपरेशंस की लागत को मापने की अनुमति देता है, और यहां तक ​​कि मुख्य प्रोसेसर संचालन में जो समय लगता है: इसके अलावा, घटाव आदि। टेक्सास इंस्ट्रूमेंट्स ने अपने प्रोसेसर के लिए दिलचस्प माप डेटा प्रस्तुत किया। LMBench C में लिखा गया है, इसलिए इसे iOS पर चलाना मुश्किल नहीं था।

मेमोरी की लागत

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

मेमोरी एक्सेस

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

आप पहले से ही प्रारंभिक परिणाम देख चुके हैं। L1 कैश के मामले में, यह 10 नैनोसेकंड से कम है, L2 के लिए यह दसियों नैनोसेकंड का एक जोड़ा है, और मुख्य मेमोरी के मामले में, समय सैकड़ों नैनोसेकंड तक बढ़ जाता है।

पढ़ने और लिखने की गति

तीन मुख्य आपरेशनों को मापा जाता है:

• पठन ( पी [i] + ) - हम तत्वों को पढ़ते हैं और उन्हें कुल राशि में जोड़ते हैं;
• रिकॉर्ड ( पी [i] = 1 ) - प्रत्येक तत्व में एक स्थिर संख्या लिखी जाती है;
• पढ़ना और लिखना ( p [i] = p [i] * 2 ) - हम तत्व को बाहर निकालते हैं, इसे बदलते हैं और नया मान वापस लिखते हैं।

बफर के साथ काम करते समय, 2 दृष्टिकोण का उपयोग किया जाता है: पहले मामले में, केवल हर चौथे तत्व का उपयोग किया जाता है, और दूसरे में, सभी तत्व क्रमिक रूप से होते हैं।



उच्चतम गति एक छोटे बफर आकार के साथ प्राप्त की जाती है, और फिर एल 1 और एल 2 कैश के आकार के अनुसार स्पष्ट चरण होते हैं। सबसे दिलचस्प बात यह है कि जब डेटा क्रमिक रूप से पढ़ा जाता है, तो कोई गति में कमी नहीं होती है। लेकिन पास होने के मामले में, स्पष्ट कदम दिखाई दे रहे हैं।



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

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

	एल 1	एल 2	स्मृति
विलंबता संख्या	1 एन.एस.	7 एन.एस.	100 एन.एस.
आईफोन 5 एस	7 एन.एस.	30 एन.एस.	240 एन.एस.
iPhone 6s प्लस	5 एन.एस.	12 एन.एस.	200 एन.एस.
iPhone X	2 एन.एस.	12 एन.एस.	146 एन.एस.

सूत्रण लागत

अगला, मैं मल्टीथ्रेडिंग का उपयोग करने की लागत को समझने के लिए थ्रेड्स के साथ काम करने के लिए समान डेटा प्राप्त करना चाहता था: एक धागा बनाने और एक थ्रेड से दूसरे थ्रेड पर स्विच करने के लिए कितना खर्च होता है। हमारे लिए, ये लगातार संचालन हैं, और मैं नुकसान को समझना चाहता हूं।

उपकरण। सिस्टम ट्रेस

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

1. सिस्टम कॉल उन्हें लाल "सॉसेज" के रूप में प्रस्तुत किया जाता है। जब आप उन्हें इंगित करते हैं, तो आप सिस्टम विधि का नाम और निष्पादन की अवधि देख सकते हैं। अक्सर एप्लिकेशन अनुप्रयोगों में, ऐसी प्रणाली कॉल सीधे नहीं होती है: हम कुछ का उपयोग करते हैं, जो बदले में पहले से ही सिस्टम विधि को कॉल करता है। आपको इस तथ्य पर भरोसा नहीं करना चाहिए कि यहां आपके कोड से विधियां दिखाई देंगी।
2. मेमोरी संचालन । उन्हें नीले "सॉसेज" के रूप में प्रस्तुत किया जाता है। इसमें मेमोरी एलोकेशन, फ्रीिंग, जीरोइंग आदि जैसे ऑपरेशन शामिल हैं।
3. स्ट्रीम स्थिति । नीला रंग - एक धागा चल रहा है, कुछ प्रोसेसर इस धागे से कोड निष्पादित कर रहा है। ग्रे - धागा किसी कारण से अवरुद्ध है और निष्पादन जारी नहीं रख सकता है। लाल - धागा काम करने के लिए तैयार है, लेकिन इस समय इसके कोड को निष्पादित करने के लिए कोई मुफ्त कर्नेल नहीं है। नारंगी रंग - उच्च प्राथमिकता वाले काम के लिए प्रवाह बाधित होता है।
4. रुचि के अंक । ये विशेष लेबल हैं जिन्हें कोड द्वारा kdebug_signpost कॉल करके व्यवस्थित किया जा सकता है। लेबल एकल हो सकते हैं (कोड में एक विशिष्ट स्थान) या एक सीमा के रूप में (पूरी प्रक्रिया को उजागर करने के लिए)। इस तरह के लेबल का उपयोग करना, आपके एप्लिकेशन के साथ माइक्रोसेकंड और सिस्टम कॉल को सहसंबंधित करना बहुत आसान है।

स्ट्रीम निर्माण लागत

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



सिस्टम ट्रेस में आप स्पष्ट रूप से देख सकते हैं कि वास्तव में सब कुछ कैसे होता है:

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

नतीजतन, एक स्ट्रीम बनाने के लिए काफी महत्वपूर्ण लागतों की आवश्यकता होती है: iPhone 5S - 230 माइक्रोसेकंड, 6S - 50 माइक्रोसेकंड। निर्माण पूरा होने में धारा की तुलना में लगभग 2 गुना अधिक समय लगता है , जुड़ने में एक मूर्त समय भी लगता है। स्मृति के साथ काम करते समय, हमें सैकड़ों नैनोसेकंड मिले, जो दसियों माइक्रोसेकंड से 100 गुना कम है।

	भूमि के ऊपर	बनाने	अंत	में शामिल होने के
आईफोन 5 एस	230 μs है	40 μs	70 μs	30 μs है
iPhone 6s प्लस	50 μs	12 μs है	20 μs	7 μs

सेमाफोर स्विचिंग टाइम

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



सिस्टम ट्रेस में, सब कुछ समान दिखता है:

1. दूसरी धारा के सेमाफोर के लिए एक संकेत दिया जाता है। यह देखा जा सकता है कि यह ऑपरेशन बहुत छोटा है।
2. दूसरा धागा अनलॉक किया गया है, इसके सेमीफोर पर इंतजार खत्म होता है।
3. पहली धारा के सेमाफोर के लिए एक संकेत दिया गया है।
4. पहले धागे को अनब्लॉक किया गया है, इसके सेमाफोर पर इंतजार खत्म होता है।

स्विचिंग का समय 10 माइक्रोसेकंड के भीतर था। 50 बार थ्रेड बनाने के साथ अंतर यही कारण है कि थ्रेड पूल बनाए जाते हैं, और प्रत्येक प्रक्रिया के लिए एक नया धागा नहीं है।

सिस्टम थ्रेड संदर्भ स्विचिंग पर नुकसान

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

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



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


हालांकि, थ्रेड्स की संख्या में वृद्धि के साथ, औसत संचालन समय नहीं बढ़ता है।

सिद्धांत रूप में, औसत समय को तब तक रखा जाना चाहिए जब तक लोड प्रसंस्करण शक्ति से मेल नहीं खाता। यही है, कार्यों की संख्या कोर की संख्या से मेल खाती है।



यदि आप समानांतर में कई कार्य चलाते हैं, तो ओएस, एक कार्य से दूसरे में स्विच कर रहा है, अतिरिक्त देरी का परिचय देगा। यह परिणाम में परिलक्षित होना चाहिए।


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



नीचे प्रवाह और सेमाफोर पर डेटा के साथ हमारी लेटेंसी नंबर तालिका है।

	एल 1	एल 2	स्मृति	सिकंदरा
विलंबता संख्या	1 एन.एस.	7 एन.एस.	100 एन.एस.	25 एन.एस.
आईफोन 5 एस	7 एन.एस.	30 एन.एस.	240 एन.एस.	8 μs है
iPhone 6s प्लस	5 एन.एस.	12 एन.एस.	200 एन.एस.	5 μs
iPhone X	2 एन.एस.	12 एन.एस.	146 एन.एस.	3.2 μs

फ़ाइल की लागत

हमारे पास पहले से ही मेमोरी और थ्रेड हैं - पूर्णता के लिए हमें केवल फ़ाइल सिस्टम ऑपरेशन की आवश्यकता है।

फ़ाइल पढ़ें

पहला परीक्षण पढ़ने की गति है - एक फ़ाइल को पढ़ने में कितना खर्च होता है। परीक्षण में दो भाग होते हैं। पहले में, हम फ़ाइल को खोलने, पढ़ने और बंद करने के लिए पढ़ने की गति को मापते हैं । दूसरे में, हम मानते हैं कि फ़ाइल लगातार खुली है : हम खुद को कहीं और रखते हैं और जितना चाहें उतना पढ़ सकते हैं।

परिणामों को दो दृष्टिकोणों से सही ढंग से देखा जाता है। जब फ़ाइल छोटी होती है , तो फ़ाइल से डेटा पढ़ने के लिए कुछ न्यूनतम समय होता है। एक किलोबाइट तक 5.3 माइक्रोसेकंड है - यह कोई बात नहीं: 1 बाइट, 2 या 1 केबी - सभी 5.3 μs के लिए। इसलिए, आप बड़ी फ़ाइलों के मामले में केवल गति के बारे में बात कर सकते हैं, जब निश्चित समय पहले से ही उपेक्षित हो सकता है। फ़ाइल को खोलने और बंद करने का ऑपरेशन किसी भी फ़ाइल आकार के लिए लगभग एक ही समय लेता है - 5 एस के मामले में, लगभग 50 माइक्रोसेकंड।



पढ़ने की गति के लिए, ऐसे ग्राफ प्राप्त किए जाते हैं।



IPhone X और 1 MB की फ़ाइल के लिए, गति 20 MB / s तक पहुँच सकती है। दिलचस्प है, 1 एमबी फ़ाइल पढ़ना अधिक कुशल है। बड़े फ़ाइल आकार के साथ, कैश आकार प्रभावित होने लगते हैं। यही कारण है कि गति आगे गिरती है और 10 एमबी के क्षेत्र में विकसित होती है।

फ़ाइलें बनाएं और हटाएं

परीक्षण में एक फ़ाइल बनाने और डेटा लिखने के चरण और बनाई गई फ़ाइलों को हटाने के चरण शामिल हैं। परिणाम स्टेप वाइज है: छोटे आकार पर, समय स्थिर है - लगभग 7 μs, और आगे बढ़ रहा है। पैमाना लघुगणक है।



मुझे आश्चर्य हुआ कि एक बड़ी फ़ाइल को हटाने में लगने वाला समय कम्यूनिकेट करने में लगने वाला समय है, क्योंकि मैंने माना कि डिलीट करना एक त्वरित ऑपरेशन है। यह पता चला है कि iPhone के लिए, समय में हटाना फ़ाइल बनाने के लिए तुलनीय है। सारांश तालिका इस प्रकार दिखती है।

	एल 1	एल 2	स्मृति	सिकंदरा	डिस्क
विलंबता संख्या	1 एन.एस.	7 एन.एस.	100 एन.एस.	25 एन.एस.	150 μs है
आईफोन 5 एस	7 एन.एस.	30 एन.एस.	240 एन.एस.	8 μs है	5 μs
iPhone 6s प्लस	5 एन.एस.	12 एन.एस.	200 एन.एस.	5 μs	4 μs
iPhone X	2 एन.एस.	12 एन.एस.	146 एन.एस.	3.2 μs	1.3 μs है

निष्कर्ष

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

आवेदन में एक भौतिक रूप से ध्यान देने योग्य हैंग पाने के लिए, प्रक्रिया का निष्पादन समय 15 मिलीसेकंड (60fps पर स्क्रीन को अपडेट करने में लगने वाला समय) से अधिक होना चाहिए। यह लेख में लिए गए अधिकांश मापों से लगभग एक हजार गुना बड़ा है। इस तरह के पैमाने पर, एक मिलीसेकंड काफी है, और एक दूसरा पहले से ही "हमेशा के लिए" है।

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

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

खैर, निष्कर्ष में, मैं आपको प्रदर्शन पर काम करते समय सबसे महत्वपूर्ण नियम याद दिलाना चाहूंगा - पहले माप और उसके बाद ही अनुकूलन !

GitHub पर प्रोफाइल स्पीकर दिमित्री कुर्किन।

AppsConf 2018 की रिपोर्टों में रूपांतरण और परिवर्तन सभी नए 2019 सम्मेलन की तैयारी के साथ समानांतर में चलते हैं। अब तक स्वीकृत रिपोर्टों की सूची में केवल 7 विषय हैं, लेकिन यह सूची हर समय विस्तारित होगी ताकि मोबाइल डेवलपर्स के लिए एक शांत सम्मेलन 22-23 अप्रैल को हो ।

प्रकाशनों का पालन करें, यूट्यूब चैनल और न्यूज़लेटर की सदस्यता लें और यह समय जल्दी से उड़ जाएगा।