পারফর্ম্যান্স মূল্যায়ন করা

ডিভাইসের পারফর্ম্যান্স মূল্যায়ন করতে Simpleperf ব্যবহার করুন। Simpleperf হল Android-এ অ্যাপ ও নেটিভ প্রসেস, দু'টির জন্যই নেটিভ প্রোফাইলিং টুল। রিয়েল টাইমে অ্যাপের CPU ব্যবহার ও থ্রেড অ্যাক্টিভিটি খতিয়ে দেখতে CPU প্রোফাইলার ব্যবহার করুন।

পারফর্ম্যান্সের দুটি ব্যবহারকারী-দৃশ্যমান সূচক রয়েছে:

• আন্দাজ করা যায়, বোঝা যায় এমন পারফর্ম্যান্স। ব্যবহারকারীর ইন্টারফেস (UI) কি ফ্রেম ড্রপ করে বা ধারাবাহিকভাবে ৬০FPS-এ রেন্ডার করে? আর্টিফ্যাক্ট বা পপিং ছাড়াই কি অডিও চলছে? ব্যবহারকারী স্ক্রিন স্পর্শ করার কতক্ষণ পরে ডিসপ্লেতে এফেক্ট দেখা যায়?
• দীর্ঘ অপারেশন সম্পূর্ণ করতে প্রয়োজনীয় সময় (যেমন অ্যাপ খোলা)।

প্রথমটি দ্বিতীয়টির চেয়ে বেশি চোখে পড়ছে। ব্যবহারকারীরা সাধারণত জ্যাঙ্ক লক্ষ্য করেন, কিন্তু তারা দুটি ডিভাইস পাশাপাশি না রাখলে ৫০০ মিলি সেকেন্ডের বনাম ৬০০ মিলি সেকেন্ডের অ্যাপ স্টার্ট-আপ টাইম বলতে পারবেন না। টাচ লেটেন্সি অবিলম্বে লক্ষ্য করা যায় এবং ডিভাইসের পারসেপশনে উল্লেখযোগ্যভাবে অবদান রাখে।

ফলে, দ্রুত ডিভাইসগুলিতে, UI পাইপলাইনকে কার্যকরী রাখার জন্য প্রয়োজনীয় বিষয়গুলি ছাড়া, সিস্টেমের মধ্যে UI পাইপলাইনই সবচেয়ে গুরুত্বপূর্ণ বিষয়। এর অর্থ হল, UI পাইপলাইনকে এমন কোনও কাজকে অগ্রাধিকার দিতে হবে যা ফ্লুইড UI-এর জন্য প্রয়োজনীয় নয়। সাবলীল UI বজায় রাখতে, UI কাজ করতে পারলে ব্যাকগ্রাউন্ড সিঙ্ক করা, বিজ্ঞপ্তি ডেলিভারি করা, এবং এই ধরনের কাজ অবশ্যই বিলম্বিত করতে হবে। ফ্লুইড UI বজায় রাখার জন্য দীর্ঘ অপারেশনের (HDR+ রানটাইম, অ্যাপ স্টার্টআপ ইত্যাদি) পারফর্ম্যান্স ট্রেড করা গ্রহণযোগ্য।

ক্যাপাসিটি বনাম জিটার

ডিভাইসের পারফর্ম্যান্স বিবেচনা করার সময়, ক্যাপাসিটি ও জিটার হল দুটি অর্থপূর্ণ মেট্রিক।

ধারণক্ষমতা

ক্ষমতা হল কোনও নির্দিষ্ট সময়ের মধ্যে ডিভাইসে থাকা কোনও রিসোর্সের মোট পরিমাণ। এটি CPU রিসোর্স, GPU রিসোর্স, I/O রিসোর্স, নেটওয়ার্ক রিসোর্স, মেমরি ব্যান্ডউইথ বা এই ধরনের কোনও মেট্রিক হতে পারে। সম্পূর্ণ সিস্টেমের পারফর্ম্যান্স পরীক্ষা করার সময়, স্বতন্ত্র কম্পোনেন্টকে অ্যাবস্ট্রাক্ট করা এবং পারফর্ম্যান্স নির্ধারণকারী একটি মেট্রিক অনুমান করা সহায়ক হতে পারে (বিশেষত নতুন ডিভাইস টিউন করার সময় কারণ সেই ডিভাইসে রান করা ওয়ার্কলোড সম্ভবত ফিক্সড)।

অনলাইনে উপলভ্য কম্পিউটিং রিসোর্সের উপর ভিত্তি করে কোনও সিস্টেমের ক্ষমতা পরিবর্তিত হয়। CPU/GPU ফ্রিকোয়েন্সি পরিবর্তন করা হল ক্যাপাসিটি পরিবর্তন করার প্রাথমিক উপায়, কিন্তু অন্যান্য উপায়ও আছে, যেমন অনলাইন CPU কোরের সংখ্যা পরিবর্তন করা। সেই অনুযায়ী, কোনও সিস্টেমের ক্ষমতা বিদ্যুৎ খরচের সাথে সামঞ্জস্যপূর্ণ; ক্ষমতা পরিবর্তন করলে বিদ্যুৎ খরচেও একই ধরনের পরিবর্তন হয়।

কোনও নির্দিষ্ট সময়ে প্রয়োজনীয় ক্যাপাসিটি মূলত নির্ধারিত হয় চালু থাকা অ্যাপের মাধ্যমে। এর ফলে, কোনও নির্দিষ্ট ওয়ার্কলোডের জন্য প্রয়োজনীয় ক্যাপাসিটি অ্যাডজাস্ট করার ক্ষেত্রে প্ল্যাটফর্মের ভূমিকা খুবই সীমিত এবং তা করার উপায় রানটাইম ইম্প্রুভমেন্টের (Android ফ্রেমওয়ার্ক, ART, Bionic, GPU কম্পাইলার/ড্রাইভার, কার্নেল) মধ্যেই সীমাবদ্ধ।

জিটার

ওয়ার্কলোডের জন্য প্রয়োজনীয় ক্যাপাসিটি সহজেই দেখা গেলেও, জিটার হল আরও অস্পষ্ট ধারণা। দ্রুত সিস্টেমের ক্ষেত্রে জিটার একটি বাধা, এই বিষয়ে ভালভাবে জানতে The Case of the Missing Supercomputer Performance: Achieving Optimal Performance on the 8,192 processors of ASCI Q শীর্ষক পেপারটি পড়লে ভাল হয়। (এটি হল ASCI Q সুপারকম্পিউটার কেন প্রত্যাশিত পারফর্ম্যান্স করতে পারেনি তার তদন্ত এবং এটি বড় সিস্টেম অপ্টিমাইজ করার একটি দুর্দান্ত ভূমিকা।)

ASCI Q পেপারে যাকে নয়েজ বলা হয়, এই পৃষ্ঠায় তাকেই জিটার বলা হয়েছে। জিটার হল সিস্টেমের এলোমেলো আচরণ যা কাজকে চলতে বাধা দেয়। এটি প্রায়শই এমন কাজ যা অবশ্যই চালাতে হবে, তবে এটির জন্য কঠোর সময়ের প্রয়োজনীয়তা নাও থাকতে পারে যার কারণে এটি কোনও নির্দিষ্ট সময়ে চলে। যেহেতু এটি র‍্যান্ডম, তাই নির্দিষ্ট ওয়ার্কলোডের জন্য জিটারের অস্তিত্ব ভুল প্রমাণ করা অত্যন্ত কঠিন। এছাড়াও, এটি প্রমাণ করা অত্যন্ত কঠিন যে জিটারের পরিচিত সোর্স একটি নির্দিষ্ট পারফর্ম্যান্স সমস্যার কারণ। জিটার (যেমন, ট্রেসিং বা লগিং) হওয়ার কারণ নির্ণয় করার জন্য সবচেয়ে সাধারণ টুলগুলি তাদের নিজস্ব জিটার প্রবর্তন করতে পারে।

Android-এর বাস্তব প্রয়োগে জিটার হওয়ার কারণগুলির মধ্যে এগুলি অন্তর্ভুক্ত:

• শিডিউলারের ক্ষেত্রে বিলম্ব
• ইন্টারাপ্ট হ্যান্ডলার
• প্রিএমশন বা ইন্টারাপ্ট বন্ধ করে ড্রাইভার কোড অনেকক্ষণ ধরে চলছে
• দীর্ঘ সময় ধরে চলা softirqs
• লক কনটেনশন (অ্যাপ, ফ্রেমওয়ার্ক, কার্নেল ড্রাইভার, বাইন্ডার লক, mmap লক)
• ফাইল ডেসক্রিপটর কনটেনশন যেখানে কম-অগ্রাধিকারের থ্রেড কোনও ফাইল লক করে রাখে, যার ফলে বেশি-অগ্রাধিকারের থ্রেড রান করতে পারে না
• ওয়ার্ককিউতে UI-এর জন্য গুরুত্বপূর্ণ কোড চালানো যেখানে এটি বিলম্বিত হতে পারে
• সিপিইউ (CPU) আইডল ট্রানজিশন
• লগিং
• I/O সংক্রান্ত দেরি
• অপ্রয়োজনীয় প্রসেস তৈরি করা (যেমন, CONNECTIVITY_CHANGE ব্রডকাস্ট)
• পর্যাপ্ত ফ্রি মেমরি না থাকার কারণে পেজ ক্যাশে থ্র্যাশিং

কোনও নির্দিষ্ট সময়ের জন্য প্রয়োজনীয় জিটারের পরিমাণ, ক্যাপাসিটি বাড়লে কমতে পারে বা নাও কমতে পারে। যেমন, i2c বাস থেকে রিড করার জন্য অপেক্ষা করার সময় কোনও ড্রাইভার যদি ইন্টারাপ্ট বন্ধ করে রাখে, তাহলে CPU-এর স্পিড ৩৮৪ মেগাহার্টজ বা ২ গিগাহার্টজ যাই হোক না কেন, এটি একটি নির্দিষ্ট সময় নেবে। জিটার থাকলে, ক্যাপাসিটি বাড়ানো পারফর্ম্যান্স উন্নত করার উপযুক্ত সমাধান নয়। এর ফলে, জিটার-সংকুচিত পরিস্থিতিতে সাধারণত দ্রুত প্রসেসর পারফর্ম্যান্স উন্নত করে না।

অবশেষে, ক্যাপাসিটির মতো নয়, জিটার প্রায় সম্পূর্ণভাবে সিস্টেম ভেন্ডরের ডোমেনের মধ্যে থাকে।

মেমরির ব্যবহার

খারাপ পারফর্ম্যান্সের জন্য সাধারণত মেমরি খরচকে দায়ী করা হয়। যদিও কনজাম্পশন নিজে পারফর্ম্যান্স সংক্রান্ত সমস্যা নয়, তবে এটি লোমেমরি কিলার ওভারহেড, সার্ভিস রিস্টার্ট ও পেজ ক্যাশে থ্র্যাশিংয়ের মাধ্যমে জিটার সৃষ্টি করতে পারে। মেমরি ব্যবহার কমালে পারফর্ম্যান্স খারাপ হওয়ার প্রত্যক্ষ কারণ এড়ানো যায়, কিন্তু অন্যান্য টার্গেট করা উন্নতিও থাকতে পারে যা সেইসব কারণ এড়িয়ে যায় (যেমন, ফ্রেমওয়ার্ককে পিন করা যাতে সেটি পেজ ইন হওয়ার পরে শীঘ্রই পেজ আউট হয়ে না যায়)।

প্রাথমিক ডিভাইস পারফর্ম্যান্স বিশ্লেষণ করা

ফাংশনাল কিন্তু খারাপ পারফর্ম করা সিস্টেম থেকে শুরু করে ব্যবহারকারীর চোখে খারাপ পারফর্ম্যান্সের স্বতন্ত্র কেস দেখে সিস্টেমের আচরণ ঠিক করার চেষ্টা করা ভাল কৌশল নয়। কারণ খারাপ পারফর্ম্যান্স সাধারণত সহজে রিপ্রোডিউস করা যায় না (অর্থাৎ, জিটার) অথবা অ্যাপের সমস্যা, সম্পূর্ণ সিস্টেমে অনেক ভেরিয়েবল এই স্ট্র্যাটেজিকে কার্যকর হতে বাধা দেয়। এর ফলে, কারণগুলি ভুলভাবে শনাক্ত করা এবং ছোটখাটো উন্নতি করা খুব সহজ, তবে সিস্টেম জুড়ে পারফর্ম্যান্স ঠিক করার জন্য সিস্টেমিক সুযোগগুলি মিস করা হয়।

পরিবর্তে, নতুন ডিভাইস কানেক্ট করার সময় নিম্নলিখিত সাধারণ পদ্ধতি ব্যবহার করুন:

1. সব ড্রাইভার ও কিছু বেসিক ফ্রিকোয়েন্সি গভর্নর সেটিংস সহ UI-তে সিস্টেম বুট করুন (আপনি ফ্রিকোয়েন্সি গভর্নর সেটিংস পরিবর্তন করলে, নিচের সব ধাপ আবার করুন)।
2. কার্নেল যাতে sched_blocked_reason ট্রেসপয়েন্ট এবং ডিসপ্লে পাইপলাইনে অন্যান্য ট্রেসপয়েন্ট সাপোর্ট করে তা নিশ্চিত করুন, যা ফ্রেমটি কখন ডিসপ্লেতে ডেলিভার করা হয় তা নির্দেশ করে।
3. লাইটওয়েট ও কনসিস্টেন্ট ওয়ার্কলোড (যেমন, UiBench অথবা TouchLatency-তে বল টেস্ট) চালানোর সময় সম্পূর্ণ UI পাইপলাইনের (IRQ-এর মাধ্যমে ইনপুট পাওয়ার থেকে ফাইনাল স্ক্যানআউট পর্যন্ত) দীর্ঘ ট্রেস নিন।
4. লাইটওয়েট ও কনসিস্টেন্ট ওয়ার্কলোডে শনাক্ত করা ফ্রেম ড্রপ সংক্রান্ত সমস্যার সমাধান করুন।
5. একবারে ২০+ সেকেন্ডের জন্য ড্রপ করা ফ্রেম শূন্য না হওয়া পর্যন্ত ৩-৪ নম্বর ধাপগুলি পুনরাবৃত্তি করুন।
6. জ্যাঙ্ক সংক্রান্ত অন্যান্য ব্যবহারকারী-দৃশ্যমান সোর্সে যান।

ডিভাইস ব্রিং-আপের প্রাথমিক পর্যায়ে আপনি অন্যান্য যেসব সহজ কাজ করতে পারেন তার মধ্যে এগুলি অন্তর্ভুক্ত:

• আপনার কার্নেলে sched_blocked_reason ট্রেসপয়েন্ট প্যাচ আছে কিনা তা নিশ্চিত করুন। এই ট্রেসপয়েন্টটি systrace-এ sched ট্রেস ক্যাটেগরির সাথে চালু করা হয় এবং সেই থ্রেড ইন্টারাপ্ট করা যায় না এমন ঘুমের মধ্যে প্রবেশ করলে, ঘুমের জন্য দায়ী ফাংশন প্রদান করে। পারফর্ম্যান্স বিশ্লেষণের জন্য এটি খুবই গুরুত্বপূর্ণ কারণ নিরবচ্ছিন্ন স্লিপ হল জিটারের একটি খুব সাধারণ সূচক।
• GPU এবং ডিসপ্লে পাইপলাইনের জন্য আপনার কাছে পর্যাপ্ত ট্রেসিং আছে কিনা তা নিশ্চিত করুন। সাম্প্রতিক Qualcomm SOC-তে, ট্রেসপয়েন্ট চালু করা হয়:

adb shell "echo 1 > /d/tracing/events/kgsl/enable"
adb shell "echo 1 > /d/tracing/events/mdss/enable"

আপনি systrace রান করালে এইসব ইভেন্ট চালু থাকে, ফলে আপনি mdss_fb0 বিভাগে ডিসপ্লে পাইপলাইন (MDSS) সম্পর্কে ট্রেসে অতিরিক্ত তথ্য দেখতে পাবেন। Qualcomm SOC-এ, আপনি স্ট্যান্ডার্ড সিস্ট্রেস ভিউতে GPU সম্পর্কে কোনও অতিরিক্ত তথ্য দেখতে পাবেন না, তবে ফলাফলগুলি ট্রেসেই উপস্থিত থাকে (বিশদ বিবরণের জন্য, সিস্ট্রেস বোঝা দেখুন)।

এই ধরনের ডিসপ্লে ট্রেসিং থেকে আপনি যা চান তা হল একটি ইভেন্ট যা সরাসরি ইঙ্গিত করে যে ডিসপ্লেতে একটি ফ্রেম ডেলিভার করা হয়েছে। সেখান থেকে, আপনি ফ্রেম টাইম সফলভাবে হিট করেছেন কিনা তা নির্ধারণ করতে পারবেন; যদি ইভেন্ট Xn-1-এর পরে ১৬.৭ মিলি সেকেন্ডের কম সময়ে ইভেন্ট Xn ঘটে (৬০ Hz ডিসপ্লে ধরে নেওয়া হচ্ছে), তাহলে আপনি বুঝবেন যে জাঙ্ক হয়নি। আপনার SOC যদি এই ধরনের সিগন্যাল প্রদান না করে, তাহলে সেগুলি পেতে আপনার ভেন্ডরের সাথে কাজ করুন। ফ্রেম সম্পূর্ণ হওয়ার কোনও নির্দিষ্ট সিগন্যাল না থাকলে জিটার ডিবাগ করা অত্যন্ত কঠিন।

সিন্থেটিক বেঞ্চমার্ক ব্যবহার করা

কোনও ডিভাইসের প্রাথমিক কার্যকারিতা আছে কিনা তা নিশ্চিত করার জন্য সিন্থেটিক বেঞ্চমার্ক উপযোগী। তবে, ডিভাইসের পারফর্ম্যান্স সম্পর্কিত ধারণার প্রক্সি হিসেবে বেঞ্চমার্ককে বিবেচনা করা কার্যকর নয়।

SOC-এর সাথে অভিজ্ঞতা অনুযায়ী, SOC-এর মধ্যে সিন্থেটিক বেঞ্চমার্ক পারফর্ম্যান্সের পার্থক্য, অনুভূত UI পারফর্ম্যান্সের (ড্রপ করা ফ্রেমের সংখ্যা, ৯৯তম পার্সেন্টাইল ফ্রেম টাইম ইত্যাদি) অনুরূপ পার্থক্যের সাথে সম্পর্কিত নয়। সিন্থেটিক বেঞ্চমার্ক হল শুধুমাত্র ক্যাপাসিটি বেঞ্চমার্ক; জিটার প্রভাব এইসব বেঞ্চমার্কের পরিমাপ করা পারফর্ম্যান্সকে শুধুমাত্র বেঞ্চমার্কের বাল্ক অপারেশন থেকে সময় চুরি করার মাধ্যমে প্রভাবিত করে। এর ফলে, সিন্থেটিক বেঞ্চমার্ক স্কোর বেশিরভাগ ক্ষেত্রেই ব্যবহারকারীর অনুভূত পারফর্ম্যান্সের মেট্রিক হিসেবে অপ্রাসঙ্গিক।

দুটি SOC-এর কথা বিবেচনা করুন যেগুলি Benchmark X রান করে এবং UI-এর ১০০০ ফ্রেম রেন্ডার করে এবং মোট রেন্ডারিং সময় রিপোর্ট করে (কম স্কোর ভাল)।

• SOC 1, Benchmark X-এর প্রতিটি ফ্রেম ১০ মিলি সেকেন্ডে রেন্ডার করে এবং ১০,০০০ স্কোর পায়।
• SOC 2, ১ মিলি সেকেন্ডে ৯৯% ফ্রেম রেন্ডার করে, কিন্তু ১০০ মিলি সেকেন্ডে ১% ফ্রেম রেন্ডার করে এবং ১৯,৯০০ স্কোর পায়, যা অনেক বেশি ভালো স্কোর।

বেঞ্চমার্ক যদি প্রকৃত UI পারফর্ম্যান্সের ইঙ্গিত দেয়, তাহলে SOC 2 ব্যবহারযোগ্য হবে না। ৬০ Hz রিফ্রেশ রেট ধরে নিলে, SOC 2-এ প্রতি ১.৫ সেকেন্ড অপারেশনে একটি করে জ্যাঙ্কি ফ্রেম থাকবে। এদিকে, SOC 1 (বেঞ্চমার্ক X অনুযায়ী ধীরে SOC) সম্পূর্ণ ফ্লুইড হবে।

সমস্যার রিপোর্ট ব্যবহার করা

পারফর্ম্যান্স বিশ্লেষণের জন্য বাগ রিপোর্ট কখনও কখনও কাজে লাগে, কিন্তু এগুলি খুব বেশি ডেটা ব্যবহার করে বলে, মাঝে মাঝে হওয়া জ্যাঙ্ক সমস্যার ক্ষেত্রে এগুলি খুব কমই কাজে লাগে। কোনও নির্দিষ্ট সময়ে সিস্টেম কী করছিল সেই সম্পর্কে তারা কিছু ইঙ্গিত দিতে পারে, বিশেষ করে যদি জ্যাঙ্ক অ্যাপ ট্রানজিশনের আশেপাশে থাকে (যা একটি বাগ রিপোর্টে লগ করা হয়)। এছাড়াও, বাগ রিপোর্ট থেকে বোঝা যেতে পারে যে সিস্টেমের মধ্যে কোনও সমস্যা রয়েছে যা এর কার্যকর ক্ষমতাকে কমিয়ে দিতে পারে (যেমন, থার্মাল থ্রটলিং বা মেমরি ফ্র্যাগমেন্টেশন)।

TouchLatency ব্যবহার করুন

খারাপ পারফর্ম্যান্সের বেশ কিছু উদাহরণ TouchLatency থেকে পাওয়া যায়, যা হল Pixel এবং Pixel XL-এর জন্য ব্যবহৃত পছন্দের পর্যায়ক্রমিক ওয়ার্কলোড। এটি frameworks/base/tests/TouchLatency-এ উপলভ্য এবং এর দুটি মোড আছে: টাচ ল্যাটেন্সি ও বাউন্সিং বল (মোড পরিবর্তন করতে, উপরের ডানদিকের কোণে থাকা বোতামে ক্লিক করুন)।

বাউন্সিং বল টেস্টটি ঠিক ততটাই সহজ যতটা এটি দেখতে লাগে: একটি বল ব্যবহারকারীর ইনপুট নির্বিশেষে স্ক্রিনের চারপাশে অনবরত বাউন্স করে। এছাড়াও, এটি সাধারণত অনেক বেশি কঠিন পরীক্ষা যা নিখুঁতভাবে চালানো যায় না, তবে এটি যত বেশি ফ্রেম ড্রপ না করে চলতে পারবে, আপনার ডিভাইস তত ভাল হবে। বাউন্সিং বল পরীক্ষাটি কঠিন কারণ এটি একটি তুচ্ছ কিন্তু নিখুঁতভাবে সামঞ্জস্যপূর্ণ ওয়ার্কলোড যা খুব কম ক্লকে চলে (এটি ধরে নেয় যে ডিভাইসে একটি ফ্রিকোয়েন্সি গভর্নর আছে; ডিভাইসটি যদি পরিবর্তে ফিক্সড ক্লক সহ চলছে, তাহলে প্রথমবার বাউন্সিং বল পরীক্ষা চালানোর সময় CPU/GPU-কে ন্যূনতমের কাছাকাছি ডাউনক্লক করুন)। সিস্টেম কোয়েসেন্স এবং ক্লক স্পিড কমে গিয়ে আইডল স্পিডের কাছাকাছি চলে এলে, প্রতি ফ্রেমের জন্য প্রয়োজনীয় CPU/GPU টাইম বেড়ে যায়। আপনি বল দেখতে পাবেন এবং জিনিসপত্র কেমন যেন নড়াচড়া করছে বলে মনে হবে এবং আপনি সিস্ট্রেসেও মিস করা ফ্রেম দেখতে পাবেন।

ওয়ার্কলোড যেহেতু খুব সুসংগত, তাই UI পাইপলাইনের পরিবর্তে প্রতিটি মিস করা ফ্রেমের সময় সিস্টেমে ঠিক কী রান করছে তা ট্র্যাক করে, আপনি বেশিরভাগ ব্যবহারকারী-দৃশ্যমান ওয়ার্কলোডের তুলনায় অনেক সহজে জিটারের বেশিরভাগ সোর্স শনাক্ত করতে পারবেন। কম ক্লক স্পিড জিটারের প্রভাবকে বাড়িয়ে দেয়, কারণ এর ফলে জিটারের কারণে ফ্রেম ড্রপ হওয়ার সম্ভাবনা বেড়ে যায়। এর ফলে, TouchLatency 60FPS-এর যত কাছাকাছি হবে, তত কম সম্ভাবনা থাকবে যে আপনার সিস্টেমে এমন কোনও সমস্যা হবে যা বড় অ্যাপে অনিয়মিত, কঠিন-পুনরুৎপাদনযোগ্য জ্যাঙ্ক তৈরি করে।

যেহেতু জিটার প্রায়শই (তবে সবসময় নয়) ক্লকস্পিড-ইনভেরিয়েন্ট হয়, তাই এমন একটি পরীক্ষা ব্যবহার করুন যা নিম্নলিখিত কারণে জিটার নির্ণয় করার জন্য খুব কম ক্লকে চলে:

• সব জিটার ক্লকস্পিড-ইনভেরিয়েন্ট নয়; অনেক সোর্স শুধু CPU টাইম ব্যবহার করে।
• ক্লকিং ডাউন করে গভর্নরকে ডেডলাইনের কাছাকাছি গড় ফ্রেম টাইম পেতে হবে, তাই UI-এর বাইরের কাজ করতে খরচ করা সময় ফ্রেম ড্রপ করার জন্য এটিকে প্রান্তের দিকে ঠেলে দিতে পারে।