একটি ডিভাইসের কর্মক্ষমতা মূল্যায়ন করার জন্য Simpleperf ব্যবহার করুন। Simpleperf হল একটি নেটিভ প্রোফাইলিং টুল অ্যান্ড্রয়েডে অ্যাপ এবং নেটিভ প্রসেস উভয়ের জন্য। রিয়েল টাইমে অ্যাপ CPU ব্যবহার এবং থ্রেড কার্যকলাপ পরিদর্শন করতে CPU প্রোফাইলার ব্যবহার করুন।
কর্মক্ষমতার দুটি ব্যবহারকারী-দৃশ্যমান সূচক রয়েছে:
- অনুমানযোগ্য, উপলব্ধিযোগ্য কর্মক্ষমতা । ইউজার ইন্টারফেস (UI) কি ফ্রেম ড্রপ করে বা ধারাবাহিকভাবে 60FPS এ রেন্ডার করে? আর্টিফ্যাক্ট বা পপিং ছাড়া অডিও প্লে হয়? ব্যবহারকারীর স্ক্রীন স্পর্শ করা এবং ডিসপ্লেতে প্রভাব দেখানোর মধ্যে কতক্ষণ বিলম্ব হয়?
- দীর্ঘ ক্রিয়াকলাপের জন্য প্রয়োজনীয় সময়ের দৈর্ঘ্য (যেমন অ্যাপ খোলা)।
প্রথমটি দ্বিতীয়টির চেয়ে বেশি লক্ষণীয়। ব্যবহারকারীরা সাধারণত জ্যাঙ্ক লক্ষ্য করে তবে তারা 500 ms বনাম 600 ms অ্যাপ শুরুর সময় বলতে পারবে না যদি না তারা পাশাপাশি দুটি ডিভাইসের দিকে না তাকিয়ে থাকে। টাচ লেটেন্সি অবিলম্বে লক্ষণীয় এবং একটি ডিভাইসের উপলব্ধিতে উল্লেখযোগ্যভাবে অবদান রাখে।
ফলস্বরূপ, একটি দ্রুত ডিভাইসে, UI পাইপলাইনটি কার্যকরী রাখার জন্য যা প্রয়োজন তা ছাড়া সিস্টেমে সবচেয়ে গুরুত্বপূর্ণ জিনিস হল UI পাইপলাইন৷ এর মানে হল যে UI পাইপলাইনটি অন্য যেকোন কাজকে অগ্রাহ্য করবে যা তরল UI এর জন্য প্রয়োজনীয় নয়। একটি তরল UI বজায় রাখার জন্য, ব্যাকগ্রাউন্ড সিঙ্কিং, নোটিফিকেশন ডেলিভারি, এবং অনুরূপ কাজগুলিকে অবশ্যই বিলম্বিত করতে হবে যদি UI কাজ চালানো যায়। একটি তরল UI বজায় রাখার জন্য দীর্ঘ ক্রিয়াকলাপগুলির (HDR+ রানটাইম, অ্যাপ স্টার্টআপ, ইত্যাদি) পারফরম্যান্স ট্রেড করা গ্রহণযোগ্য।
ক্ষমতা বনাম জিটার
ডিভাইসের কর্মক্ষমতা বিবেচনা করার সময়, ক্ষমতা এবং জিটার দুটি অর্থবহ মেট্রিক।
ক্ষমতা
ক্যাপাসিটি হল কিছু রিসোর্সের মোট পরিমাণ যা ডিভাইসের কিছু সময়ের জন্য থাকে। এটি CPU সংস্থান, GPU সংস্থান, I/O সংস্থান, নেটওয়ার্ক সংস্থান, মেমরি ব্যান্ডউইথ বা অনুরূপ মেট্রিক হতে পারে। সম্পূর্ণ-সিস্টেম কর্মক্ষমতা পরীক্ষা করার সময়, পৃথক উপাদানগুলিকে বিমূর্ত করা এবং কর্মক্ষমতা নির্ধারণ করে এমন একটি একক মেট্রিক অনুমান করা উপযোগী হতে পারে (বিশেষ করে যখন একটি নতুন ডিভাইস টিউন করা হয় কারণ সেই ডিভাইসে চালিত কাজের চাপগুলি সম্ভবত স্থির থাকে)।
অনলাইনে কম্পিউটিং সংস্থানগুলির উপর ভিত্তি করে একটি সিস্টেমের ক্ষমতা পরিবর্তিত হয়। CPU/GPU ফ্রিকোয়েন্সি পরিবর্তন করা হল ক্ষমতা পরিবর্তনের প্রাথমিক উপায়, কিন্তু অনলাইনে CPU কোরের সংখ্যা পরিবর্তন করার মতো আরও কিছু আছে। তদনুসারে, একটি সিস্টেমের ক্ষমতা শক্তি খরচের সাথে মিলে যায়; ক্ষমতা পরিবর্তনের ফলে সর্বদা বিদ্যুৎ খরচে একই রকম পরিবর্তন হয়।
একটি নির্দিষ্ট সময়ে প্রয়োজনীয় ক্ষমতা অত্যধিকভাবে চলমান অ্যাপ দ্বারা নির্ধারিত হয়। ফলস্বরূপ, প্ল্যাটফর্মটি প্রদত্ত কাজের চাপের জন্য প্রয়োজনীয় ক্ষমতা সামঞ্জস্য করতে খুব কমই করতে পারে এবং এটি করার উপায়গুলি রানটাইম উন্নতির মধ্যে সীমাবদ্ধ (অ্যান্ড্রয়েড ফ্রেমওয়ার্ক, এআরটি, বায়োনিক, জিপিইউ কম্পাইলার/ড্রাইভার, কার্নেল)।
জিটার
যদিও কাজের চাপের জন্য প্রয়োজনীয় ক্ষমতা দেখা সহজ, জীটার একটি আরও অস্পষ্ট ধারণা। দ্রুত সিস্টেমের প্রতিবন্ধকতা হিসাবে জিটারের একটি ভাল ভূমিকার জন্য, অনুপস্থিত সুপারকম্পিউটার পারফরমেন্সের কেসটি পড়ুন: ASCl Q-এর 8,192 প্রসেসরগুলিতে সর্বোত্তম পারফরমেন্স অর্জন করা। (এটি একটি তদন্ত যে কেন ASCI Q সুপার কম্পিউটার তার প্রত্যাশিত কর্মক্ষমতা অর্জন করতে পারেনি এবং এটি বড় সিস্টেমগুলিকে অপ্টিমাইজ করার একটি দুর্দান্ত ভূমিকা।)
এই পৃষ্ঠাটি জিটার শব্দটি ব্যবহার করে তা বর্ণনা করতে ASCI Q কাগজ যাকে শব্দ বলে। জিটার হল র্যান্ডম সিস্টেমের আচরণ যা উপলব্ধিযোগ্য কাজকে চলতে বাধা দেয়। এটি প্রায়শই কাজ যা অবশ্যই চালানো উচিত, তবে এটিতে কঠোর সময়ের প্রয়োজনীয়তা নাও থাকতে পারে যা এটিকে কোনো নির্দিষ্ট সময়ে চালানোর কারণ হতে পারে। কারণ এটি এলোমেলো, প্রদত্ত কাজের চাপের জন্য জিটারের অস্তিত্বকে অস্বীকার করা অত্যন্ত কঠিন। এটি প্রমাণ করাও অত্যন্ত কঠিন যে জিটারের একটি পরিচিত উৎস একটি নির্দিষ্ট কর্মক্ষমতা সমস্যার কারণ ছিল। জিটারের কারণগুলি নির্ণয়ের জন্য সাধারণত ব্যবহৃত সরঞ্জামগুলি (যেমন ট্রেসিং বা লগিং) তাদের নিজস্ব জিটার প্রবর্তন করতে পারে।
অ্যান্ড্রয়েডের বাস্তব-বিশ্ব বাস্তবায়নে অভিজ্ঞ জিটারের উত্সগুলির মধ্যে রয়েছে:
- সময়সূচী বিলম্ব
- হ্যান্ডলার বাধা
- প্রিম্পশন বা বাধা অক্ষম সহ ড্রাইভার কোড খুব বেশি সময় ধরে চলছে৷
- দীর্ঘমেয়াদী সফ্টির্কস
- লক বিতর্ক (অ্যাপ, ফ্রেমওয়ার্ক, কার্নেল ড্রাইভার, বাইন্ডার লক, mmap লক)
- ফাইল বর্ণনাকারী বিতর্ক যেখানে একটি নিম্ন-অগ্রাধিকার থ্রেড একটি ফাইলের লক ধরে রাখে, একটি উচ্চ-অগ্রাধিকার থ্রেডকে চলতে বাধা দেয়
- কাজের সারিতে UI- সমালোচনামূলক কোড চালানো যেখানে এটি বিলম্বিত হতে পারে
- CPU নিষ্ক্রিয় রূপান্তর
- লগিং
- I/O বিলম্ব
- অপ্রয়োজনীয় প্রক্রিয়া তৈরি (উদাহরণস্বরূপ,
CONNECTIVITY_CHANGEসম্প্রচার) - অপর্যাপ্ত ফ্রি মেমরির কারণে পৃষ্ঠা ক্যাশে থ্র্যাশিং
একটি নির্দিষ্ট সময়ের জন্য প্রয়োজনীয় সময় কম্পনের ক্ষমতা বৃদ্ধির সাথে সাথে হ্রাস পেতে পারে বা নাও হতে পারে। উদাহরণ স্বরূপ, যদি কোনো ড্রাইভার একটি i2c বাস জুড়ে রিডের জন্য অপেক্ষা করার সময় বাধা অক্ষম করে ফেলে, তাহলে সিপিইউ 384 মেগাহার্টজ বা 2 গিগাহার্টজ যাই হোক না কেন এটি একটি নির্দিষ্ট পরিমাণ সময় নেবে। ক্ষিপ্রতা জড়িত থাকলে কর্মক্ষমতা উন্নত করার জন্য ক্ষমতা বাড়ানো একটি সম্ভাব্য সমাধান নয়। ফলস্বরূপ, দ্রুততর প্রসেসরগুলি সাধারণত ঝাঁকুনিযুক্ত পরিস্থিতিতে কর্মক্ষমতা উন্নত করবে না।
অবশেষে, ক্ষমতার বিপরীতে, জিটার প্রায় সম্পূর্ণরূপে সিস্টেম বিক্রেতার ডোমেনের মধ্যে।
মেমরি খরচ
মেমরি খরচ ঐতিহ্যগতভাবে দুর্বল কর্মক্ষমতা জন্য দায়ী করা হয়. যদিও খরচ নিজেই একটি কর্মক্ষমতা সমস্যা নয়, এটি লোমেমোরিকিলার ওভারহেড, পরিষেবা পুনরায় চালু এবং পৃষ্ঠা ক্যাশে থ্র্যাশিং এর মাধ্যমে ঝাঁকুনি সৃষ্টি করতে পারে। মেমরি খরচ হ্রাস করা খারাপ কর্মক্ষমতার সরাসরি কারণগুলিকে এড়াতে পারে, তবে অন্যান্য লক্ষ্যযুক্ত উন্নতি হতে পারে যা সেই কারণগুলিকেও এড়াতে পারে (উদাহরণস্বরূপ, ফ্রেমওয়ার্কটিকে পিন করা যাতে এটি শীঘ্রই পৃষ্ঠায় করা হবে তখন এটিকে পেজ করা থেকে আটকাতে)।
প্রাথমিক ডিভাইস কর্মক্ষমতা বিশ্লেষণ
একটি কার্যকরী কিন্তু খারাপ-পারফর্মিং সিস্টেম থেকে শুরু করে এবং ব্যবহারকারী-দৃশ্যমান খারাপ পারফরম্যান্সের পৃথক ক্ষেত্রে দেখে সিস্টেমের আচরণ ঠিক করার চেষ্টা করা একটি সঠিক কৌশল নয় । কারণ দুর্বল কর্মক্ষমতা সাধারণত সহজে পুনরুত্পাদনযোগ্য নয় (অর্থাৎ, জিটার) বা একটি অ্যাপ সমস্যা, সম্পূর্ণ সিস্টেমে অনেকগুলি ভেরিয়েবল এই কৌশলটিকে কার্যকর হতে বাধা দেয়। ফলস্বরূপ, কারণগুলিকে ভুল শনাক্ত করা এবং সিস্টেম জুড়ে কার্যকারিতা ঠিক করার জন্য সিস্টেমিক সুযোগগুলি মিস করার সময় সামান্য উন্নতি করা খুব সহজ।
পরিবর্তে, একটি নতুন ডিভাইস আনার সময় নিম্নলিখিত সাধারণ পদ্ধতি ব্যবহার করুন:
- চলমান সমস্ত ড্রাইভার এবং কিছু মৌলিক ফ্রিকোয়েন্সি গভর্নর সেটিংস সহ UI-তে সিস্টেম বুটিং পান (যদি আপনি ফ্রিকোয়েন্সি গভর্নর সেটিংস পরিবর্তন করেন, নীচের সমস্ত পদক্ষেপগুলি পুনরাবৃত্তি করুন)।
- নিশ্চিত করুন যে কার্নেলটি
sched_blocked_reasonট্রেসপয়েন্ট এবং সেইসাথে ডিসপ্লে পাইপলাইনের অন্যান্য ট্রেসপয়েন্ট সমর্থন করে যা ডিসপ্লেতে ফ্রেম বিতরণ করার সময় নির্দেশ করে। - হালকা এবং সামঞ্জস্যপূর্ণ কাজের চাপ (উদাহরণস্বরূপ, UiBench বা TouchLatency এ বল পরীক্ষা) চালানোর সময় পুরো UI পাইপলাইনের দীর্ঘ ট্রেস নিন (একটি IRQ এর মাধ্যমে ইনপুট গ্রহণ থেকে চূড়ান্ত স্ক্যানআউট পর্যন্ত)।
- হালকা ওজনের এবং সামঞ্জস্যপূর্ণ কাজের চাপে সনাক্ত করা ফ্রেম ড্রপগুলি ঠিক করুন।
- আপনি একবারে 20+ সেকেন্ডের জন্য শূন্য ড্রপ করা ফ্রেমের সাথে চালানো না হওয়া পর্যন্ত ধাপ 3-4 পুনরাবৃত্তি করুন।
- জ্যাঙ্কের অন্যান্য ব্যবহারকারী-দৃশ্যমান উত্সগুলিতে যান৷
ডিভাইস আনার শুরুতে আপনি অন্যান্য সহজ জিনিসগুলি করতে পারেন:
- আপনার কার্নেলে sched_blocked_reason ট্রেসপয়েন্ট প্যাচ আছে তা নিশ্চিত করুন। এই ট্রেসপয়েন্টটি সিস্ট্রেসে নির্ধারিত ট্রেস বিভাগের সাথে সক্রিয় করা হয়েছে এবং যখন সেই থ্রেডটি নিরবচ্ছিন্ন ঘুমে প্রবেশ করে তখন ঘুমের জন্য দায়ী ফাংশন প্রদান করে। কর্মক্ষমতা বিশ্লেষণের জন্য এটি গুরুত্বপূর্ণ কারণ নিরবচ্ছিন্ন ঘুম হল জিটারের একটি খুব সাধারণ সূচক।
- GPU এবং ডিসপ্লে পাইপলাইনের জন্য আপনার পর্যাপ্ত ট্রেসিং আছে তা নিশ্চিত করুন। সাম্প্রতিক কোয়ালকম এসওসিগুলিতে, ট্রেসপয়েন্টগুলি ব্যবহার করে সক্রিয় করা হয়েছে:
adb shell "echo 1 > /d/tracing/events/kgsl/enable"adb shell "echo 1 > /d/tracing/events/mdss/enable"
আপনি যখন সিস্ট্রেস চালান তখন এই ইভেন্টগুলি সক্রিয় থাকে যাতে আপনি mdss_fb0 বিভাগে ডিসপ্লে পাইপলাইন (MDSS) সম্পর্কে ট্রেসে অতিরিক্ত তথ্য দেখতে পারেন। Qualcomm SOCs-এ, আপনি স্ট্যান্ডার্ড সিস্ট্রেস ভিউতে GPU সম্পর্কে কোনও অতিরিক্ত তথ্য দেখতে পাবেন না, তবে ফলাফলগুলি ট্রেসেই উপস্থিত থাকে (বিস্তারিত জানার জন্য, সিস্ট্রেস বোঝা দেখুন)।
এই ধরনের ডিসপ্লে ট্রেসিং থেকে আপনি যা চান তা হল একটি একক ইভেন্ট যা সরাসরি নির্দেশ করে যে একটি ফ্রেম ডিসপ্লেতে পৌঁছে দেওয়া হয়েছে। সেখান থেকে, আপনি নির্ধারণ করতে পারেন যে আপনি আপনার ফ্রেম টাইম সফলভাবে হিট করেছেন কিনা; যদি ইভেন্ট X n -1 ইভেন্টের পরে 16.7 ms এর কম সময়ে ঘটে (একটি 60 Hz ডিসপ্লে ধরে নেওয়া হয়), তাহলে আপনি জানেন যে আপনি জ্যাঙ্ক করেননি। যদি আপনার SOC এই ধরনের সংকেত প্রদান না করে, সেগুলি পেতে আপনার বিক্রেতার সাথে কাজ করুন। ফ্রেম সমাপ্তির একটি নির্দিষ্ট সংকেত ছাড়াই ডিবাগিং জিটার অত্যন্ত কঠিন।
সিন্থেটিক বেঞ্চমার্ক ব্যবহার করুন
একটি ডিভাইসের মৌলিক কার্যকারিতা উপস্থিত রয়েছে তা নিশ্চিত করার জন্য সিন্থেটিক বেঞ্চমার্কগুলি কার্যকর। যাইহোক, অনুভূত ডিভাইস কর্মক্ষমতা জন্য একটি প্রক্সি হিসাবে মানদণ্ড বিবেচনা করা দরকারী নয়।
SOCs-এর অভিজ্ঞতার উপর ভিত্তি করে, SOC-এর মধ্যে সিন্থেটিক বেঞ্চমার্ক পারফরম্যান্সের পার্থক্যগুলি উপলব্ধিযোগ্য UI কর্মক্ষমতার (ড্রপ করা ফ্রেমের সংখ্যা, 99 তম পার্সেন্টাইল ফ্রেম টাইম, ইত্যাদি) অনুরূপ পার্থক্যের সাথে সম্পর্কিত নয়। সিন্থেটিক বেঞ্চমার্কগুলি শুধুমাত্র ক্ষমতার মানদণ্ড; জিটার শুধুমাত্র বেঞ্চমার্কের বাল্ক অপারেশন থেকে সময় চুরি করে এই বেঞ্চমার্কের পরিমাপ করা কর্মক্ষমতাকে প্রভাবিত করে। ফলস্বরূপ, সিন্থেটিক বেঞ্চমার্ক স্কোরগুলি বেশিরভাগই ব্যবহারকারী-অনুভূত কর্মক্ষমতা মেট্রিক হিসাবে অপ্রাসঙ্গিক।
বেঞ্চমার্ক X চলমান দুটি SOC বিবেচনা করুন যা 1000 ফ্রেম UI রেন্ডার করে এবং মোট রেন্ডারিং সময় রিপোর্ট করে (নিম্ন স্কোর ভাল)।
- SOC 1 বেঞ্চমার্ক X এর প্রতিটি ফ্রেম 10 ms এ রেন্ডার করে এবং 10,000 স্কোর করে।
- SOC 2 1 ms-এ 99% ফ্রেম রেন্ডার করে কিন্তু 100 ms-এ 1% ফ্রেম রেন্ডার করে এবং 19,900 স্কোর করে, একটি নাটকীয়ভাবে ভালো স্কোর।
যদি বেঞ্চমার্ক প্রকৃত UI কর্মক্ষমতা নির্দেশ করে, SOC 2 অব্যবহারযোগ্য হবে। একটি 60 Hz রিফ্রেশ রেট ধরে নিলে, SOC 2-এর প্রতি 1.5 সেকেন্ড অপারেশনে একটি জ্যাঙ্কি ফ্রেম থাকবে। এদিকে, SOC 1 (বেঞ্চমার্ক X অনুযায়ী ধীর SOC) পুরোপুরি তরল হবে।
বাগ রিপোর্ট ব্যবহার করুন
বাগ রিপোর্টগুলি কখনও কখনও কর্মক্ষমতা বিশ্লেষণের জন্য উপযোগী হয়, কিন্তু যেহেতু সেগুলি এত ভারী, তাই তারা বিক্ষিপ্ত জ্যাঙ্ক সমস্যাগুলি ডিবাগ করার জন্য খুব কমই কার্যকর। একটি নির্দিষ্ট সময়ে সিস্টেমটি কী করছে সে সম্পর্কে তারা কিছু ইঙ্গিত দিতে পারে, বিশেষ করে যদি জ্যাঙ্কটি একটি অ্যাপ ট্রানজিশনের কাছাকাছি ছিল (যা একটি বাগ রিপোর্টে লগ ইন করা আছে)। বাগ রিপোর্টগুলিও নির্দেশ করতে পারে যখন সিস্টেমের সাথে আরও বিস্তৃতভাবে কিছু ভুল হয় যা এর কার্যকর ক্ষমতা হ্রাস করতে পারে (যেমন থার্মাল থ্রটলিং বা মেমরি ফ্র্যাগমেন্টেশন)।
টাচ লেটেন্সি ব্যবহার করুন
খারাপ আচরণের বেশ কয়েকটি উদাহরণ TouchLatency থেকে এসেছে, যা Pixel এবং Pixel XL-এর জন্য ব্যবহৃত পছন্দের পর্যায়ক্রমিক কাজের চাপ। এটি frameworks/base/tests/TouchLatency উপলব্ধ এবং দুটি মোড রয়েছে: টাচ লেটেন্সি এবং বাউন্সিং বল (মোড স্যুইচ করতে, উপরের-ডান কোণে বোতামে ক্লিক করুন)।
বাউন্সিং বলের পরীক্ষাটি যতটা দেখা যাচ্ছে ঠিক ততটাই সহজ: ব্যবহারকারীর ইনপুট নির্বিশেষে একটি বল চিরতরে স্ক্রিনের চারপাশে বাউন্স করে। এটি সাধারণত নিখুঁতভাবে চালানোর জন্য সবচেয়ে কঠিন পরীক্ষা, কিন্তু কোন ড্রপ ফ্রেম ছাড়াই এটি চালানোর যত কাছাকাছি আসবে, আপনার ডিভাইস তত ভাল হবে। বাউন্সিং বলের পরীক্ষাটি কঠিন কারণ এটি একটি তুচ্ছ কিন্তু পুরোপুরি সামঞ্জস্যপূর্ণ কাজের চাপ যা খুব কম ঘড়িতে চলে (এটি অনুমান করে যে ডিভাইসটির একটি ফ্রিকোয়েন্সি গভর্নর রয়েছে; যদি ডিভাইসটি স্থির ঘড়ির পরিবর্তে চলমান থাকে, তবে CPU/GPU-কে ন্যূনতম-নূন্যতম ঘড়িতে নামিয়ে দিন প্রথমবার বাউন্সিং বলের পরীক্ষা চালানোর সময়)। সিস্টেম স্তব্ধ হয়ে যাওয়ার সাথে সাথে ঘড়িগুলি নিষ্ক্রিয় হওয়ার কাছাকাছি চলে যায়, ফ্রেমে প্রয়োজনীয় CPU/GPU সময় বৃদ্ধি পায়। আপনি বলটি দেখতে পারেন এবং জিনিসগুলি জ্যাঙ্ক দেখতে পারেন এবং আপনি সিস্ট্রেসে মিস করা ফ্রেমগুলিও দেখতে সক্ষম হবেন।
যেহেতু কাজের চাপ এতই সামঞ্জস্যপূর্ণ, আপনি UI পাইপলাইনের পরিবর্তে প্রতিটি মিস করা ফ্রেমের সময় সিস্টেমে ঠিক কী চলছে তা ট্র্যাক করে বেশিরভাগ ব্যবহারকারী-দৃশ্যমান ওয়ার্কলোডের তুলনায় জিটারের বেশিরভাগ উত্স সনাক্ত করতে পারেন। নীচের ঘড়িগুলি জীটার প্রভাবকে আরও বাড়িয়ে তোলে যে কোনও ঝাঁকুনি একটি ড্রপ ফ্রেম সৃষ্টি করে। ফলস্বরূপ, 60FPS এর কাছাকাছি TouchLatency, আপনার খারাপ সিস্টেম আচরণ হওয়ার সম্ভাবনা তত কম যা বড় অ্যাপগুলিতে বিক্ষিপ্ত, পুনরুত্পাদন করা কঠিন জ্যাঙ্ক সৃষ্টি করে।
যেহেতু জিটার প্রায়শই (কিন্তু সর্বদা নয়) ক্লকস্পিড-অপরিবর্তনশীল, তাই নিম্নোক্ত কারণগুলির জন্য জিটার নির্ণয়ের জন্য একটি পরীক্ষা ব্যবহার করুন যা খুব কম ঘড়িতে চলে:
- সব জিটার ঘড়ির গতি-অপরিবর্তনীয় নয়; অনেক উৎস শুধু CPU সময় গ্রাস করে।
- গভর্নরকে ক্লক ডাউন করে নির্দিষ্ট সময়সীমার কাছাকাছি গড় ফ্রেম টাইম পাওয়া উচিত, তাই নন-ইউআই কাজ চালানোর সময় এটি একটি ফ্রেম ড্রপ করার প্রান্তে ঠেলে দিতে পারে।