किसी डिवाइस की परफ़ॉर्मेंस का आकलन करने के लिए, Simpleperf का इस्तेमाल करें. Simpleperf, Android पर ऐप्लिकेशन और नेटिव प्रोसेस, दोनों के लिए एक नेटिव प्रोफ़ाइलिंग टूल है. ऐप्लिकेशन में सीपीयू के इस्तेमाल और थ्रेड गतिविधि की रीयल टाइम में जांच करने के लिए, सीपीयू प्रोफ़ाइलर का इस्तेमाल करें.
उपयोगकर्ताओं को परफ़ॉर्मेंस के दो इंडिकेटर दिखते हैं:
- अनुमानित और समझने में आसान परफ़ॉर्मेंस. क्या यूज़र इंटरफ़ेस (यूआई) में फ़्रेम ड्रॉप होते हैं या यह लगातार 60 फ़्रेम प्रति सेकंड (एफ़पीएस) पर रेंडर होता है? क्या ऑडियो में कोई गड़बड़ी या आवाज़ में रुकावट तो नहीं आ रही है? उपयोगकर्ता के स्क्रीन को छूने और डिसप्ले पर असर दिखने के बीच कितना समय लगता है?
- ज़्यादा समय लेने वाली कार्रवाइयों में लगने वाला समय (जैसे कि ऐप्लिकेशन खोलना).
पहली इमेज, दूसरी इमेज की तुलना में ज़्यादा ध्यान खींचने वाली है. आम तौर पर, लोगों को जंक का पता चल जाता है. हालांकि, वे ऐप्लिकेशन के स्टार्टअप में लगने वाले समय के बीच अंतर नहीं बता पाएंगे. जैसे, 500 मि॰से॰ बनाम 600 मि॰से॰. ऐसा तब तक नहीं हो पाएगा, जब तक वे दो डिवाइसों को एक साथ न देख रहे हों. टच में लगने वाला समय तुरंत पता चल जाता है. इससे डिवाइस के बारे में लोगों की राय पर काफ़ी असर पड़ता है.
इसलिए, तेज़ डिवाइस में यूज़र इंटरफ़ेस (यूआई) पाइपलाइन, सिस्टम में सबसे अहम होती है. इसके अलावा, यूज़र इंटरफ़ेस (यूआई) पाइपलाइन को चालू रखने के लिए ज़रूरी चीज़ें भी अहम होती हैं. इसका मतलब है कि यूज़र इंटरफ़ेस (यूआई) पाइपलाइन को ऐसे किसी भी काम को प्राथमिकता देनी चाहिए जो फ़्लूड यूज़र इंटरफ़ेस (यूआई) के लिए ज़रूरी नहीं है. यूज़र इंटरफ़ेस (यूआई) को बेहतर बनाए रखने के लिए, बैकग्राउंड सिंक करने, सूचनाएं भेजने, और इसी तरह के अन्य कामों को तब तक के लिए रोक देना चाहिए, जब तक यूआई से जुड़ा काम पूरा न हो जाए. यूज़र इंटरफ़ेस (यूआई) को बेहतर बनाए रखने के लिए, लंबी अवधि तक चलने वाली कार्रवाइयों (एचडीआर+ रनटाइम, ऐप्लिकेशन स्टार्टअप वगैरह) की परफ़ॉर्मेंस को कम किया जा सकता है.
क्षमता बनाम जिटर
डिवाइस की परफ़ॉर्मेंस का आकलन करते समय, क्षमता और जिटर दो अहम मेट्रिक हैं.
क्षमता
क्षमता, किसी डिवाइस के पास कुछ समय के लिए मौजूद संसाधन की कुल मात्रा होती है. यह सीपीयू संसाधन, जीपीयू संसाधन, I/O संसाधन, नेटवर्क संसाधन, मेमोरी बैंडविड्थ या ऐसी ही कोई अन्य मेट्रिक हो सकती है. पूरे सिस्टम की परफ़ॉर्मेंस की जांच करते समय, अलग-अलग कॉम्पोनेंट को अलग करना और परफ़ॉर्मेंस तय करने वाली एक मेट्रिक का इस्तेमाल करना फ़ायदेमंद हो सकता है. ऐसा खास तौर पर तब होता है, जब किसी नए डिवाइस को ट्यून किया जा रहा हो, क्योंकि उस डिवाइस पर चलने वाले वर्कलोड तय होते हैं.
किसी सिस्टम की क्षमता, ऑनलाइन कंप्यूटिंग संसाधनों के आधार पर अलग-अलग होती है. सीपीयू/जीपीयू की फ़्रीक्वेंसी बदलकर, क्षमता में बदलाव किया जा सकता है. हालांकि, इसके अलावा और भी तरीके हैं. जैसे, सीपीयू कोर की संख्या को ऑनलाइन बदलना. इसलिए, किसी सिस्टम की क्षमता, बिजली की खपत से जुड़ी होती है. क्षमता में बदलाव करने से, बिजली की खपत में भी उसी तरह का बदलाव होता है.
किसी भी समय, ज़रूरी क्षमता का ज़्यादातर हिस्सा, चालू ऐप्लिकेशन तय करता है. इसलिए, प्लैटफ़ॉर्म किसी दिए गए वर्कलोड के लिए ज़रूरी क्षमता को अडजस्ट करने के लिए बहुत कम काम कर सकता है. साथ ही, ऐसा करने के तरीके, रनटाइम में सुधार (Android फ़्रेमवर्क, ART, Bionic, GPU कंपाइलर/ड्राइवर, कर्नल) तक सीमित हैं.
सिग्नल में गड़बड़ी
किसी वर्कलोड के लिए ज़रूरी क्षमता को आसानी से देखा जा सकता है. हालांकि, जिटर एक ऐसा कॉन्सेप्ट है जिसे समझना थोड़ा मुश्किल है. तेज़ सिस्टम के लिए, जिटर के बारे में अच्छी जानकारी पाने के लिए, हमारा सुझाव है कि आप The Case of the Missing Supercomputer Performance: Achieving Optimal Performance on the 8,192 processors of ASCI Q नाम का पेपर पढ़ें. (इसमें यह जांच की गई है कि एएससीआईक्यू सुपरकंप्यूटर, उम्मीद के मुताबिक परफ़ॉर्म क्यों नहीं कर सका. साथ ही, यह बड़े सिस्टम को ऑप्टिमाइज़ करने के बारे में एक बेहतरीन जानकारी है.)
इस पेज पर, ASCI Q पेपर में बताए गए नॉइज़ के बारे में बताने के लिए, जिटर शब्द का इस्तेमाल किया गया है. सिस्टम में अचानक होने वाले बदलावों को जिटर कहते हैं. इनकी वजह से, काम ठीक से नहीं हो पाता. यह अक्सर ऐसा काम होता है जिसे पूरा करना ज़रूरी होता है. हालांकि, इसके लिए समयसीमा तय नहीं होती. इसलिए, इसे किसी भी समय पूरा किया जा सकता है. यह रैंडम होता है. इसलिए, किसी दिए गए वर्कलोड के लिए जिटर के मौजूद होने की बात को गलत साबित करना बहुत मुश्किल होता है. यह साबित करना भी बहुत मुश्किल है कि जिटर की वजह से परफ़ॉर्मेंस से जुड़ी कोई समस्या हुई है. जिटर की वजहों का पता लगाने के लिए, सबसे ज़्यादा इस्तेमाल किए जाने वाले टूल (जैसे कि ट्रेसिंग या लॉगिंग) से जिटर हो सकता है.
Android के असल दुनिया में इस्तेमाल किए जाने वाले वर्शन में जिटर के ये सोर्स शामिल हैं:
- शेड्यूलर में देरी
- इंटरप्ट हैंडलर
- ड्राइवर कोड बहुत देर से चल रहा है और इसमें प्रीएम्प्शन या इंटरप्ट की सुविधा बंद है
- लंबे समय तक चलने वाले सॉफ़्टवेयर इंटरप्ट
- लॉक का विवाद (ऐप्लिकेशन, फ़्रेमवर्क, कर्नल ड्राइवर, बाइंडर लॉक, mmap लॉक)
- फ़ाइल डिस्क्रिप्टर का विवाद, जिसमें कम प्राथमिकता वाला थ्रेड किसी फ़ाइल पर लॉक रखता है. इससे ज़्यादा प्राथमिकता वाले थ्रेड को चलने से रोका जाता है
- वर्कक्यू में यूज़र इंटरफ़ेस (यूआई) से जुड़े ज़रूरी कोड को चलाने पर, उसमें देरी हो सकती है
- सीपीयू के आइडल ट्रांज़िशन
- लॉग इन हो रहा है
- I/O में होने वाली देरी
- ज़रूरत न होने पर भी प्रोसेस बनाना (उदाहरण के लिए,
CONNECTIVITY_CHANGEब्रॉडकास्ट) - मेमोरी में जगह कम होने की वजह से, पेज कैश मेमोरी थ्रैशिंग की समस्या हुई
बैंडविथ बढ़ने पर, किसी समयावधि के लिए ज़रूरी जिटर की मात्रा कम हो सकती है या नहीं भी हो सकती. उदाहरण के लिए, अगर कोई ड्राइवर i2c बस से डेटा पढ़ने के दौरान इंटरप्ट बंद कर देता है, तो डेटा पढ़ने में उतना ही समय लगेगा जितना पहले लगता था. भले ही, सीपीयू 384 मेगाहर्ट्ज़ पर काम कर रहा हो या 2 गीगाहर्ट्ज़ पर. अगर जिटर की समस्या हो, तो बैंडविड्थ बढ़ाने से परफ़ॉर्मेंस बेहतर नहीं होती. इस वजह से, आम तौर पर, तेज़ प्रोसेसर से जिटर की समस्या वाली स्थितियों में परफ़ॉर्मेंस बेहतर नहीं होती है.
आखिर में, क्षमता के उलट, जिटर लगभग पूरी तरह से सिस्टम वेंडर के डोमेन में होता है.
मेमोरी का इस्तेमाल
आम तौर पर, खराब परफ़ॉर्मेंस के लिए मेमोरी के इस्तेमाल को ज़िम्मेदार ठहराया जाता है. हालांकि, मेमोरी का इस्तेमाल करना परफ़ॉर्मेंस से जुड़ी समस्या नहीं है. फिर भी, इसकी वजह से जिटर की समस्या हो सकती है. ऐसा लोमेमोरीकिलर ओवरहेड, सर्विस रीस्टार्ट, और पेज कैश थ्रैशिंग की वजह से होता है. मेमोरी का इस्तेमाल कम करने से, खराब परफ़ॉर्मेंस की वजहों से बचा जा सकता है. हालांकि, परफ़ॉर्मेंस को बेहतर बनाने के लिए अन्य तरीके भी अपनाए जा सकते हैं. जैसे, फ़्रेमवर्क को पिन करना, ताकि उसे पेज आउट होने से रोका जा सके. ऐसा इसलिए, क्योंकि पेज आउट होने के तुरंत बाद उसे पेज इन कर दिया जाएगा.
डिवाइस की शुरुआती परफ़ॉर्मेंस का विश्लेषण करना
काम कर रहे सिस्टम से शुरुआत करना, लेकिन उसकी परफ़ॉर्मेंस खराब होना और उपयोगकर्ता को दिखने वाली खराब परफ़ॉर्मेंस के अलग-अलग मामलों को देखकर सिस्टम के व्यवहार को ठीक करने की कोशिश करना, एक अच्छी रणनीति नहीं है. आम तौर पर, खराब परफ़ॉर्मेंस को आसानी से दोहराया नहीं जा सकता. ऐसा इसलिए होता है, क्योंकि यह समस्या ऐप्लिकेशन से जुड़ी होती है. साथ ही, पूरे सिस्टम में बहुत ज़्यादा वैरिएबल होने की वजह से, यह रणनीति असरदार नहीं होती. इस वजह से, समस्याओं की वजहों का पता लगाने में आसानी होती है और सिस्टम की परफ़ॉर्मेंस को बेहतर बनाने के लिए, छोटे-मोटे बदलाव किए जा सकते हैं. हालांकि, इससे सिस्टम की परफ़ॉर्मेंस को बेहतर बनाने के लिए, सिस्टम से जुड़े अवसरों को अनदेखा किया जा सकता है.
इसके बजाय, नया डिवाइस चालू करते समय यह सामान्य तरीका अपनाएं:
- सिस्टम को यूज़र इंटरफ़ेस (यूआई) पर बूट करें. साथ ही, सभी ड्राइवर चालू करें और फ़्रीक्वेंसी गवर्नर की कुछ बुनियादी सेटिंग चालू करें. अगर फ़्रीक्वेंसी गवर्नर की सेटिंग बदली जाती हैं, तो नीचे दिए गए सभी चरणों को दोहराएं.
- पक्का करें कि कर्नल,
sched_blocked_reasonट्रेसपॉइंट के साथ-साथ डिसप्ले पाइपलाइन में मौजूद अन्य ट्रेसपॉइंट के साथ काम करता हो. ये ट्रेसपॉइंट यह बताते हैं कि फ़्रेम को डिसप्ले पर कब डिलीवर किया जाता है. - पूरे यूज़र इंटरफ़ेस (यूआई) पाइपलाइन के लंबे ट्रेस लें. यह ट्रेस, आईआरक्यू के ज़रिए इनपुट पाने से लेकर फ़ाइनल स्कैनआउट तक का होना चाहिए. इस दौरान, हल्के और एक जैसे वर्कलोड (उदाहरण के लिए, UiBench या TouchLatency में बॉल टेस्ट) चलाएं.
- लाइटवेट और लगातार काम करने वाले वर्कलोड में फ़्रेम ड्रॉप की समस्या ठीक की गई है.
- तीसरे और चौथे चरण को तब तक दोहराएं, जब तक कि आप एक बार में 20 सेकंड से ज़्यादा समय तक, बिना फ़्रेम ड्रॉप किए वीडियो रिकॉर्ड न कर पाएं.
- उपयोगकर्ता को दिखने वाले जंक के अन्य सोर्स पर जाएं.
डिवाइस को चालू करने के शुरुआती चरणों में, ये आसान काम किए जा सकते हैं:
- पक्का करें कि आपके कर्नल में sched_blocked_reason tracepoint patch मौजूद हो. यह ट्रेसपॉइंट, systrace में sched ट्रेस कैटगरी के साथ चालू होता है. साथ ही, यह उस फ़ंक्शन के बारे में जानकारी देता है जो थ्रेड के इंटरप्ट न किए जा सकने वाले स्लीप मोड में जाने पर, उसे स्लीप मोड में डालता है. परफ़ॉर्मेंस के विश्लेषण के लिए यह ज़रूरी है, क्योंकि बिना किसी रुकावट के नींद आना, जिटर का एक सामान्य इंडिकेटर है.
- पक्का करें कि आपके पास जीपीयू और डिसप्ले पाइपलाइन के लिए, ट्रेसिंग की सुविधा उपलब्ध हो. Qualcomm के हाल ही के एसओसी पर, ट्रेसपॉइंट इन तरीकों से चालू किए जाते हैं:
adb shell "echo 1 > /d/tracing/events/kgsl/enable"adb shell "echo 1 > /d/tracing/events/mdss/enable"
systrace चलाने पर ये इवेंट चालू रहते हैं, ताकि आपको mdss_fb0 सेक्शन में डिसप्ले पाइपलाइन (एमडीएसएस) के बारे में ज़्यादा जानकारी मिल सके. Qualcomm SOC पर, आपको स्टैंडर्ड systrace व्यू में GPU के बारे में कोई अतिरिक्त जानकारी नहीं दिखेगी. हालांकि, नतीजे ट्रेस में मौजूद होते हैं. ज़्यादा जानकारी के लिए, systrace को समझना लेख पढ़ें.
इस तरह की डिसप्ले ट्रेसिंग से आपको एक ऐसा इवेंट चाहिए जो सीधे तौर पर यह बताए कि डिसप्ले पर कोई फ़्रेम डिलीवर किया गया है. यहां से, यह पता लगाया जा सकता है कि आपने फ़्रेम टाइम को पूरा किया है या नहीं. अगर इवेंट Xn-1 के 16.7 मि॰से॰ से कम समय बाद इवेंट Xn होता है (मान लें कि डिसप्ले 60 हर्ट्ज़ का है), तो इसका मतलब है कि आपने जंक नहीं किया है. अगर आपका एसओसी ऐसे सिग्नल नहीं देता है, तो उन्हें पाने के लिए अपने वेंडर के साथ काम करें. फ़्रेम के पूरा होने का सटीक सिग्नल न मिलने पर, जिटर को डीबग करना बहुत मुश्किल होता है.
सिंथेटिक बेंचमार्क का इस्तेमाल करना
सिंथेटिक बेंचमार्क, यह पक्का करने के लिए काम आते हैं कि डिवाइस में बुनियादी सुविधाएं मौजूद हैं. हालांकि, बेंचमार्क को डिवाइस की परफ़ॉर्मेंस का प्रॉक्सी मानने से कोई फ़ायदा नहीं होता.
एसओसी के अनुभव के आधार पर, एसओसी के बीच सिंथेटिक बेंचमार्क परफ़ॉर्मेंस में अंतर, यूज़र इंटरफ़ेस (यूआई) की परफ़ॉर्मेंस में दिखने वाले अंतर से मेल नहीं खाता. जैसे, ड्रॉप किए गए फ़्रेम की संख्या, 99वें पर्सेंटाइल फ़्रेम का समय वगैरह. सिंथेटिक बेंचमार्क, सिर्फ़ क्षमता के बेंचमार्क होते हैं. जिटर का असर, इन बेंचमार्क की मेज़र की गई परफ़ॉर्मेंस पर सिर्फ़ तब पड़ता है, जब यह बेंचमार्क के बल्क ऑपरेशन से समय चुराता है. इस वजह से, सिंथेटिक बेंचमार्क स्कोर, उपयोगकर्ता की नज़र से परफ़ॉर्मेंस की मेट्रिक के तौर पर ज़्यादातर काम के नहीं होते.
मान लें कि दो एसओसी, Benchmark X चला रहे हैं. यह एसओसी, यूज़र इंटरफ़ेस (यूआई) के 1,000 फ़्रेम रेंडर करता है और रेंडरिंग में लगे कुल समय की जानकारी देता है. इसमें कम स्कोर बेहतर होता है.
- SOC 1, Benchmark X के हर फ़्रेम को 10 मि॰से॰ में रेंडर करता है और 10,000 का स्कोर करता है.
- SOC 2, 99% फ़्रेम को 1 मि॰से॰ में रेंडर करता है. हालांकि, 1% फ़्रेम को 100 मि॰से॰ में रेंडर करता है. इसका स्कोर 19,900 है, जो कि बहुत बेहतर स्कोर है.
अगर बेंचमार्क से यूज़र इंटरफ़ेस (यूआई) की असल परफ़ॉर्मेंस का पता चलता है, तो SOC 2 का इस्तेमाल नहीं किया जा सकेगा. अगर रीफ़्रेश रेट 60 हर्ट्ज़ है, तो एसओसी 2 में हर 1.5 सेकंड में एक फ़्रेम जंकी होगा. वहीं, Benchmark X के मुताबिक, SOC 1 (धीमा SOC) पूरी तरह से फ़्लूड होगा.
गड़बड़ी की रिपोर्ट का इस्तेमाल करना
कभी-कभी, परफ़ॉर्मेंस का विश्लेषण करने के लिए गड़बड़ी की रिपोर्ट काम की होती हैं. हालांकि, ये रिपोर्ट बहुत बड़ी होती हैं. इसलिए, ये कभी-कभी होने वाली जंक की समस्याओं को डीबग करने के लिए बहुत कम काम की होती हैं. इनसे यह पता चल सकता है कि सिस्टम किसी समय क्या कर रहा था. खास तौर पर, अगर ऐप्लिकेशन ट्रांज़िशन के दौरान जंक हुआ हो (जिसे गड़बड़ी की रिपोर्ट में लॉग किया जाता है). बग रिपोर्ट से यह भी पता चल सकता है कि सिस्टम में कोई ऐसी समस्या है जिसकी वजह से उसकी परफ़ॉर्मेंस पर असर पड़ सकता है. जैसे, थर्मल थ्रॉटलिंग या मेमोरी फ़्रैगमेंटेशन.
Use TouchLatency
TouchLatency से, परफ़ॉर्मेंस से जुड़ी कई समस्याएं सामने आई हैं. यह Pixel और Pixel XL के लिए, समय-समय पर इस्तेमाल किया जाने वाला पसंदीदा वर्कलोड है. यह frameworks/base/tests/TouchLatency पर उपलब्ध है. इसमें दो मोड होते हैं: टच लेटेंसी और बाउंसिंग बॉल. मोड बदलने के लिए, सबसे ऊपर दाएं कोने में मौजूद बटन पर क्लिक करें.
बाउंसिंग बॉल टेस्ट उतना ही आसान है जितना दिखता है: इसमें एक गेंद, उपयोगकर्ता के इनपुट के बावजूद स्क्रीन पर हमेशा बाउंस करती रहती है. आम तौर पर, इस टेस्ट को सही तरीके से पूरा करना सबसे मुश्किल होता है. हालांकि, अगर यह टेस्ट बिना किसी फ़्रेम के ड्रॉप हुए पूरा होता है, तो आपका डिवाइस बेहतर होगा. बाउंसिंग बॉल टेस्ट मुश्किल होता है, क्योंकि यह एक सामान्य लेकिन पूरी तरह से एक जैसा वर्कलोड होता है. यह बहुत कम क्लॉक पर चलता है. इससे यह पता चलता है कि डिवाइस में फ़्रीक्वेंसी गवर्नर है. अगर डिवाइस फ़िक्स्ड क्लॉक के साथ चल रहा है, तो पहली बार बाउंसिंग बॉल टेस्ट चलाते समय सीपीयू/जीपीयू को कम से कम क्लॉक पर सेट करें. सिस्टम के शांत होने और क्लॉक के आइडल के करीब पहुंचने पर, हर फ़्रेम के लिए ज़रूरी सीपीयू/जीपीयू का समय बढ़ जाता है. आपको गेंद दिखती रहेगी और चीज़ें अटकती हुई दिखेंगी. साथ ही, आपको सिस्टम ट्रेस में छूटे हुए फ़्रेम भी दिखेंगे.
वर्कलोड एक जैसा होने की वजह से, जिटर के ज़्यादातर सोर्स का पता लगाना बहुत आसान होता है. ऐसा इसलिए, क्योंकि यूज़र इंटरफ़ेस (यूआई) पाइपलाइन के बजाय, हर छूटे हुए फ़्रेम के दौरान सिस्टम पर चल रही प्रोसेस को ट्रैक किया जाता है. कम क्लॉक रेट की वजह से, जिटर का असर बढ़ जाता है. इससे फ़्रेम के ड्रॉप होने की संभावना बढ़ जाती है. इस वजह से, TouchLatency जितना 60 एफ़पीएस के करीब होगा, सिस्टम के खराब होने की संभावना उतनी ही कम होगी. इससे बड़े ऐप्लिकेशन में, कभी-कभी होने वाली और दोहराने में मुश्किल होने वाली जंक की समस्या नहीं होगी.
जिटर, अक्सर (लेकिन हमेशा नहीं) क्लॉकस्पीड से अलग होता है. इसलिए, जिटर का पता लगाने के लिए, बहुत कम क्लॉक पर चलने वाले टेस्ट का इस्तेमाल करें. ऐसा इन वजहों से करें:
- सभी जिटर, क्लॉकस्पीड के हिसाब से नहीं बदलते. कई सोर्स सिर्फ़ सीपीयू का समय लेते हैं.
- गवर्नर को क्लॉक डाउन करके, औसत फ़्रेम टाइम को डेडलाइन के करीब लाना चाहिए. इसलिए, यूज़र इंटरफ़ेस (यूआई) से जुड़े काम के अलावा अन्य काम करने में लगने वाला समय, फ़्रेम को ड्रॉप करने के लिए इसे काफ़ी आगे बढ़ा सकता है.