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