১৮% দ্রুত কম্পাইল, ০% আপস

Android Runtime (ART) টিম কম্পাইল করা কোড বা কোনও পিক মেমরি রিগ্রেশনকে প্রভাবিত না করেই কম্পাইল করার সময় ১৮% কমিয়েছে। মেমরি ব্যবহার বা কম্পাইল করা কোডের কোয়ালিটি না কমিয়ে কম্পাইল টাইম উন্নত করার জন্য আমাদের ২০২৫ সালের উদ্যোগের অংশ হিসেবে এই উন্নতি করা হয়েছে।

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

কম্পাইল-টাইম স্পিড সংক্রান্ত এইসব উন্নতির মধ্যে কিছু জুন ২০২৫ Android রিলিজে লঞ্চ করা হয়েছে এবং বাকিগুলি Android-এর বছর শেষের রিলিজে উপলভ্য হবে। এছাড়াও, 12 ও তার পরের যেকোনও ভার্সনের সব Android ব্যবহারকারী মেনলাইন আপডেটের মাধ্যমে এইসব উন্নতি পাবেন।

অপ্টিমাইজিং কম্পাইলারকে অপ্টিমাইজ করা

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

এইসব কঠোর মানদণ্ড পূরণের জন্য আমরা যে একটি রিসোর্স ব্যবহার করতে ইচ্ছুক ছিলাম তা হল আমাদের নিজস্ব ডেভেলপমেন্ট টাইম। এর মাধ্যমে আমরা গভীরভাবে তদন্ত করতে এবং বুদ্ধিদীপ্ত সমাধান খুঁজে পেতে পারি। উন্নতি করার জায়গা খুঁজে বের করা এবং বিভিন্ন সমস্যার সঠিক সমাধান খুঁজে পাওয়ার জন্য আমরা কীভাবে কাজ করি, আসুন তা আরও ভালোভাবে দেখে নেওয়া যাক।

সম্ভাব্য অপ্টিমাইজেশন খুঁজে দেখা

কোনও মেট্রিক অপ্টিমাইজ করা শুরু করার আগে, আপনাকে সেটি পরিমাপ করতে হবে। তা না হলে, আপনি এটি উন্নত করেছেন কিনা তা কখনই নিশ্চিত হতে পারবেন না। আমাদের সৌভাগ্য যে, আপনি যদি কিছু সতর্কতা অবলম্বন করেন, যেমন, পরিবর্তনের আগে ও পরে পরিমাপ করার জন্য একই ডিভাইস ব্যবহার করেন এবং আপনার ডিভাইস থার্মাল থ্রটল না করেন, তাহলে কম্পাইল টাইম স্পিড মোটামুটি একই থাকে। এছাড়াও, আমাদের কাছে কম্পাইলার পরিসংখ্যানের মতো ডিটারমিনিস্টিক পরিমাপও রয়েছে যা আমাদের বুঝতে সাহায্য করে যে পর্দার আড়ালে কী ঘটছে।

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

বাছাই করা APK-র সেই সেট দিয়ে আমরা লোকাল মেশিনে ম্যানুয়ালি কম্পাইল ট্রিগার করব, কম্পাইলেশনের প্রোফাইল পাব এবং pprof ব্যবহার করে দেখব যে আমরা কোথায় সময় ব্যয় করছি।

pprof-এ প্রোফাইলের ফ্লেম গ্রাফের উদাহরণ

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

এইসব ভিউয়ের মধ্যে একটি হল "নিচ থেকে উপরে" ভিউ, যেখানে আপনি দেখতে পাবেন যে কোন পদ্ধতি সবচেয়ে বেশি সময় নিচ্ছে। নিচের ছবিতে আমরা Kill নামের একটি পদ্ধতি দেখতে পাচ্ছি, যা কম্পাইল টাইমের ১%-এর বেশি। অন্যান্য সেরা পদ্ধতিগুলি সম্পর্কেও এই ব্লগ পোস্টে পরে আলোচনা করা হবে।

প্রোফাইলের নিচ থেকে উপরের দিকের ভিউ

আমাদের অপ্টিমাইজ করা কম্পাইলারে, গ্লোবাল ভ্যালু নাম্বারিং (GVN) নামে একটি ফেজ আছে। এটি সামগ্রিকভাবে কী করে তা নিয়ে আপনাকে চিন্তা করতে হবে না, তবে প্রাসঙ্গিক অংশটি হল এটিতে `Kill` নামে একটি পদ্ধতি আছে যা ফিল্টার অনুযায়ী কিছু নোড মুছে দেবে। এটি সময়সাপেক্ষ কারণ সব নোডকে ইটারেট করতে হয় এবং একটি একটি করে চেক করতে হয়। আমরা লক্ষ্য করেছি যে এমন কিছু ঘটনা আছে যেখানে আমরা আগে থেকেই জানি যে চেকটি ভুল হবে, সেই সময়ে আমাদের কাছে যে নোডই থাকুক না কেন। এইসব ক্ষেত্রে, আমরা সম্পূর্ণভাবে পুনরাবৃত্তি এড়িয়ে যেতে পারি, যার ফলে এটি ১.০২৩% থেকে কমে ~০.৩% হয়ে যায় এবং GVN-এর রানটাইম ~১৫% বেড়ে যায়।

গুরুত্বপূর্ণ অপ্টিমাইজেশন প্রয়োগ করা

আমরা কীভাবে পরিমাপ করতে হয় এবং কোথায় সময় ব্যয় হচ্ছে তা কীভাবে শনাক্ত করতে হয় সেই বিষয়ে আলোচনা করেছি, তবে এটি সবে শুরু। পরবর্তী ধাপ হল, কম্পাইল করার জন্য যে সময় ব্যয় করা হচ্ছে তা কীভাবে অপ্টিমাইজ করা যায়।

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

অন্যান্য ক্ষেত্রে, আমরা নিম্নলিখিত সহ বিভিন্ন কৌশল ব্যবহার করেছি:

• কোনও অপ্টিমাইজেশন থেকে উপযুক্ত ফলাফল পাওয়া যাবে কিনা তা হিউরিস্টিক ব্যবহার করে নির্ধারণ করা এবং সেই কারণে সেটি এড়িয়ে যাওয়া
• কম্পিউট করা ডেটা ক্যাশে করার জন্য অতিরিক্ত ডেটা স্ট্রাকচার ব্যবহার করা
• স্পিড বুস্ট পেতে বর্তমান ডেটা স্ট্রাকচার পরিবর্তন করা
• কিছু ক্ষেত্রে চক্র এড়াতে অলসভাবে ফলাফল কম্পিউট করা
• সঠিক অ্যাবস্ট্রাকশন ব্যবহার করা - অপ্রয়োজনীয় ফিচার কোডের স্পিড কমিয়ে দিতে পারে
• অনেক লোডের মাধ্যমে প্রায়শই ব্যবহৃত পয়েন্টারকে তাড়া করা এড়িয়ে চলুন

অপ্টিমাইজেশন করা উপযুক্ত কিনা তা আমরা কীভাবে বুঝব?

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

আপনি যদি একই ধরনের পরিস্থিতিতে থাকেন, তাহলে যতটা কম কাজ করে মেট্রিককে কতটা উন্নত করতে পারবেন তা অনুমান করার চেষ্টা করুন। এর অর্থ হল, এই ক্রমে:

1. আগে সংগ্রহ করা মেট্রিক বা শুধুমাত্র আন্দাজের উপর ভিত্তি করে অনুমান করা
2. দ্রুত ও অগোছালো প্রোটোটাইপ ব্যবহার করে অনুমান করা
3. একটি সমাধান প্রয়োগ করুন।

আপনার সমাধানের ত্রুটিগুলি অনুমান করার কথা বিবেচনা করতে ভুলবেন না। যেমন, আপনি যদি অতিরিক্ত ডেটা স্ট্রাকচারের উপর নির্ভর করতে চান, তাহলে আপনি কতটা মেমরি ব্যবহার করতে ইচ্ছুক?

আরও গভীরে যাওয়া

আর দেরি না করে, আমরা যেসব পরিবর্তন প্রয়োগ করেছি তার কয়েকটি দেখে নেওয়া যাক।

আমরা FindReferenceInfoOf নামের একটি পদ্ধতি অপ্টিমাইজ করার জন্য পরিবর্তন করেছি। এই পদ্ধতিতে কোনও এন্ট্রি খুঁজে পাওয়ার জন্য ভেক্টরের লিনিয়ার সার্চ করা হচ্ছিল। নির্দেশের আইডি দিয়ে ইন্ডেক্স করার জন্য আমরা ডেটা স্ট্রাকচার আপডেট করেছি যাতে FindReferenceInfoOf-এর কমপ্লেক্সিটি O(n)-এর পরিবর্তে O(1) হয়। এছাড়াও, সাইজ পরিবর্তন এড়াতে আমরা আগে থেকেই ভেক্টর বরাদ্দ করেছি। আমাদের একটি অতিরিক্ত ফিল্ড যোগ করতে হয়েছিল যা আমরা ভেক্টরে কতগুলি এন্ট্রি যোগ করেছি তা গণনা করে, তাই আমরা মেমরি কিছুটা বাড়িয়েছি, তবে এটি একটি ছোট ত্যাগ ছিল কারণ পিক মেমরি বাড়েনি। এর ফলে আমাদের LoadStoreAnalysis ফেজটি ৩৪-৬৬% দ্রুত হয়েছে, যার ফলে কম্পাইল করার সময় ~০.৫-১.৮% উন্নতি হয়েছে।

আমাদের কাছে HashSet-এর কাস্টম প্রয়োগ আছে যা আমরা বিভিন্ন জায়গায় ব্যবহার করি। এই ডেটা স্ট্রাকচার তৈরি করতে অনেক সময় লাগছিল এবং আমরা এর কারণ খুঁজে পেয়েছি। অনেক বছর আগে, এই ডেটা স্ট্রাকচার শুধুমাত্র খুব বড় HashSets ব্যবহার করা অল্প কয়েকটি জায়গায় ব্যবহার করা হত এবং সেটির জন্য অপ্টিমাইজ করার জন্য এটি পরিবর্তন করা হয়েছিল। তবে, আজকাল এটি বিপরীত দিকে ব্যবহার করা হয় এবং এতে খুব কম এন্ট্রি থাকে ও এর মেয়াদও কম হয়। এর অর্থ হল, আমরা এই বিশাল HashSet তৈরি করে সাইকেল নষ্ট করছিলাম, কিন্তু এটি বাতিল করার আগে আমরা এটি শুধুমাত্র কয়েকটি এন্ট্রির জন্য ব্যবহার করেছি। এই পরিবর্তনের মাধ্যমে, আমরা কম্পাইল টাইম ~১.৩-২% উন্নত করেছি। অতিরিক্ত সুবিধা হিসেবে, মেমরি ব্যবহার ~০.৫-১% কমে গেছে কারণ আমরা আগের মতো বড় ডেটা স্ট্রাকচার ব্যবহার করছি না।

আমরা রেফারেন্সের মাধ্যমে ডেটা স্ট্রাকচার পাস করে ল্যাম্বডাতে কম্পাইল টাইম ~০.৫-১% উন্নত করেছি যাতে সেগুলি কপি করতে না হয়। এটি আসল পর্যালোচনায় মিস হয়ে গিয়েছিল এবং আমাদের কোডবেসে বহু বছর ধরে ছিল। pprof-এ প্রোফাইলগুলি দেখার ফলেই আমরা লক্ষ্য করেছি যে এই পদ্ধতিগুলি প্রচুর ডেটা স্ট্রাকচার তৈরি ও ধ্বংস করছে, যার ফলে আমরা সেগুলি তদন্ত ও অপ্টিমাইজ করেছি।

আমরা কম্পাইল করা আউটপুট লেখার ফেজটি কম্পিউট করা ভ্যালু ক্যাশে করে দ্রুত করেছি, যার ফলে মোট কম্পাইল করার সময় ~১.৩-২.৮% কমে গেছে। তবে, অতিরিক্ত বুককিপিংয়ের কারণে সমস্যা হয়েছে এবং আমাদের অটোমেটিক টেস্টিং মেমরি রিগ্রেশন সম্পর্কে আমাদের সতর্ক করেছে। পরে, আমরা একই কোড আবার চেক করে নতুন ভার্সন প্রয়োগ করেছি যা শুধু মেমরি রিগ্রেশনই সামলায়নি, তার সাথে কম্পাইল টাইমও আরও ~০.৫-১.৮% উন্নত করেছে! এই দ্বিতীয় পরিবর্তনের সময়, দুটি ডেটা স্ট্রাকচারের মধ্যে একটিকে বাদ দেওয়ার জন্য, এই ফেজ কীভাবে কাজ করবে তা আমাদের রিফ্যাক্টর ও রিম্যাজিন করতে হয়েছে।

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

আমরা কোনও সময়-সাপেক্ষ গণনা করার আগে ইনলাইনিং সফল হবে কিনা তা অনুমান করতে, "ফাইনাল চেক" বিভাগ থেকে দুটি চেক "হিউরিস্টিক" বিভাগে সরিয়ে দিয়েছি। যেহেতু এটি একটি আনুমানিক হিসেব, তাই এটি নিখুঁত নয়, তবে আমরা যাচাই করে দেখেছি যে আমাদের নতুন হিউরিস্টিক পারফর্ম্যান্সকে প্রভাবিত না করেই আগে ইনলাইন করা কন্টেন্টের ৯৯.৯% কভার করে। এইসব নতুন হিউরিস্টিকসের মধ্যে একটি প্রয়োজনীয় DEX রেজিস্টার (~০.২-১.৩% উন্নতি) এবং অন্যটি নির্দেশাবলীর সংখ্যা (~২% উন্নতি) সম্পর্কে ছিল।

আমাদের কাছে BitVector-এর কাস্টম ইমপ্লিমেন্টেশন আছে যা আমরা বিভিন্ন জায়গায় ব্যবহার করি। নির্দিষ্ট ফিক্সড-সাইজ বিট ভেক্টরের জন্য আমরা রিসাইজ করা যায় এমন BitVector ক্লাসের পরিবর্তে আরও সহজ BitVectorView ব্যবহার করেছি। এটি কিছু ইনডাইরেকশন এবং রান-টাইম রেঞ্জ চেক বাদ দেয় এবং বিট ভেক্টর অবজেক্ট তৈরি করার প্রসেসকে দ্রুত করে।

এছাড়াও, অন্তর্নিহিত স্টোরেজ ধরনের উপর BitVectorView ক্লাসকে টেমপ্লেটাইজ করা হয়েছে (পুরনো BitVector-এর মতো সবসময় uint32_t ব্যবহার করার পরিবর্তে)। এটি কিছু অপারেশনকে, যেমন Union(), ৬৪-বিট প্ল্যাটফর্মে একসাথে দ্বিগুণ বিট প্রসেস করার অনুমতি দেয়। Android OS কম্পাইল করার সময় প্রভাবিত ফাংশনের স্যাম্পেল মোট ১%-এর বেশি কমানো হয়েছে। এটি একাধিক পরিবর্তন জুড়ে করা হয়েছে [১, ২, ৩, ৪, ৫, ৬]

আমরা যদি সব অপ্টিমাইজেশন সম্পর্কে বিস্তারিতভাবে কথা বলি, তাহলে আমাদের সারাদিন এখানে থাকতে হবে! আপনি আরও কিছু অপ্টিমাইজেশন করতে চাইলে, আমাদের প্রয়োগ করা অন্যান্য পরিবর্তনগুলি দেখুন:

• কম্পাইলেশন টাইম ~০.৬-১.৬% কমাতে বুককিপিং যোগ করুন।
• সম্ভব হলে, চক্র এড়াতে ডেটা ধীরে ধীরে গণনা করুন।
• ব্যবহার করা হবে না এমন ক্ষেত্রে আগে থেকে গণনা করার কাজ এড়াতে আমাদের কোড রিফ্যাক্টর করুন।
• অ্যালোকেটর অন্য জায়গা থেকে সহজেই পাওয়া গেলে কিছু ডিপেন্ডেন্ট লোড চেইন এড়িয়ে চলুন।
• অযথা কাজ এড়াতে চেক যোগ করার আরেকটি উদাহরণ।
• রেজিস্টার অ্যালোকেটরে রেজিস্টার টাইপ (কোর/FP)-এ ঘন ঘন ব্রাঞ্চিং এড়িয়ে চলুন।
• কম্পাইল করার সময় কিছু অ্যারে ইনিশিয়ালাইজ করা হয়েছে কিনা দেখুন। এটি করার জন্য clang-এর উপর নির্ভর করবেন না।
• কিছু লুপ পরিষ্কার করুন। রেঞ্জ লুপ ব্যবহার করুন যা clang আরও ভালভাবে অপ্টিমাইজ করতে পারে কারণ লুপের পার্শ্বপ্রতিক্রিয়ার কারণে কন্টেনারের ইন্টার্নাল পয়েন্টার রিলোড করার প্রয়োজন হয় না। প্রতিটি ইনপুটের জন্য ইনলাইন করা `InputAt(.)` ব্যবহার করে লুপে ভার্চুয়াল ফাংশন `HInstruction::GetInputRecords()` কল করা এড়িয়ে চলুন।
• কম্পাইলার অপ্টিমাইজেশন ব্যবহার করে ভিজিটর প্যাটার্নের জন্য Accept() ফাংশন এড়িয়ে চলুন।

সিদ্ধান্ত

ART-এর কম্পাইল-টাইম স্পিড উন্নত করার জন্য আমাদের প্রচেষ্টা উল্লেখযোগ্য উন্নতি এনেছে, এর ফলে Android আরও ফ্লুইড ও এফিশিয়েন্ট হয়ে উঠেছে এবং একই সাথে ব্যাটারির আয়ু ও ডিভাইস থার্মালও উন্নত হয়েছে। যত্ন সহকারে অপ্টিমাইজেশন শনাক্ত ও প্রয়োগ করার মাধ্যমে আমরা দেখিয়েছি যে মেমরি ব্যবহার বা কোডের কোয়ালিটির সাথে কোনও আপস না করেই কম্পাইল-টাইমে উল্লেখযোগ্য উন্নতি করা সম্ভব।

আমাদের এই যাত্রায় pprof-এর মতো টুল ব্যবহার করে প্রোফাইলিং করা, বারবার চেষ্টা করার মানসিকতা এবং কখনও কখনও কম ফলপ্রসূ পদ্ধতি ছেড়ে দেওয়াও অন্তর্ভুক্ত ছিল। ART টিমের সম্মিলিত প্রচেষ্টার ফলে উল্লেখযোগ্য শতাংশে কম্পাইল টাইম কমেছে এবং ভবিষ্যতে আরও উন্নতি করার জন্য ভিত্তিও তৈরি হয়েছে।

এইসব উন্নতি ২০২৫ সালের শেষদিকের Android আপডেটে এবং Android 12 ও এর পরের যেকোনও ভার্সনে মেইনলাইন আপডেটের মাধ্যমে উপলভ্য। আমরা আশা করি যে আমাদের অপ্টিমাইজেশন প্রসেস সম্পর্কে এই বিস্তারিত আলোচনা থেকে আপনি কম্পাইলার ইঞ্জিনিয়ারিংয়ের জটিলতা ও পুরস্কার সম্পর্কে মূল্যবান ইনসাইট পেয়েছেন!