নিষ্ক্রিয় অবস্থায় নীরবতা: অপ্টিমাইজেশনের আগে ও পরে Windows-এর ব্যাকগ্রাউন্ড কার্যকলাপ
На этой странице
সংক্ষিপ্ত উত্তর
Заголовок раздела «সংক্ষিপ্ত উত্তর»Windows-এর ব্যাকগ্রাউন্ড উপাদান নিষ্ক্রিয় করলে সত্যিই নিষ্ক্রিয় অবস্থায় সিস্টেমের কার্যকলাপ কমে: দুটি স্বাধীন পরিমাপ-সিরিজে প্রসেসের সংখ্যা কমেছে 49–56 %, নিষ্ক্রিয় অবস্থায় CPU ব্যবহার কমেছে 17–67 %, আর দ্বিতীয় সিরিজে মেমরি কমিটমেন্টের পরিমাণ কমেছে 52 %। তবে CPU-তে পূর্ণ লোডের অধীনে থ্রুপুট বেড়েছে মাত্র 0,2–0,5 %। «নীরব নিষ্ক্রিয় অবস্থা» বলতে ব্যাকগ্রাউন্ড কাজ ও রিসোর্সের জন্য প্রতিযোগিতা কমেছে—এটি নিশ্চিত হওয়াকে বোঝায়; FPS বৃদ্ধি নয়: এই গবেষণায় গেমিংয়ের চূড়ান্ত প্রভাব মাপা হয়নি।
অবস্থা: ভার্চুয়াল মেশিনে Windows 11-এর একই বিল্ডে দুটি স্বাধীন সিরিজে প্রভাবের দিক পুনরায় পাওয়া গেছে। সিরিজভেদে পরিমাণ আলাদা, কারণ Windows-এর ব্যাকগ্রাউন্ড কাজ ঢেউয়ের মতো আসে: Microsoft Defender স্ক্যান চলার সময়ের উইন্ডোতে CPU ব্যবহারের পার্থক্য −67 % পর্যন্ত পৌঁছায়, আর আগে থেকেই শান্ত উইন্ডোতে −17 %।
যাচাইযোগ্য দাবি
Заголовок раздела «যাচাইযোগ্য দাবি»আমরা চারটি দাবি যাচাই করেছি:
- ব্যাকগ্রাউন্ড উপাদান নিষ্ক্রিয় করলে নিষ্ক্রিয় অবস্থায় সিস্টেমের কার্যকলাপ উল্লেখযোগ্যভাবে কমে।
- এটি বুটের পর প্রথম কয়েক মিনিটে কার্যকলাপ উল্লেখযোগ্যভাবে কমায়।
- এটি মেমরির ব্যবহার উল্লেখযোগ্যভাবে কমায়।
- CPU-তে পূর্ণ লোডের অধীনে এটি পরিমাপযোগ্য কর্মক্ষমতা বৃদ্ধি দেয়।
গবেষণার পরিধি
Заголовок раздела «গবেষণার পরিধি»- Windows 11 Pro, build 26300.9457 (26H2);
- ভার্চুয়াল মেশিন: 4 vCPU, 8 GB RAM, VMware ভার্চুয়ালাইজেশন;
- একই ইনস্টলেশনের দুটি অবস্থা: মূল («আগে») এবং BoosterX অপ্টিমাইজেশন প্রোফাইল প্রয়োগের পর (পরিমাপের তারিখে সর্বশেষ বিল্ড);
- পরিমাপের দুটি স্বাধীন সিরিজ: 2026-09-18 এবং 2026-09-19; পরিমাপ যাতে একে অপরকে প্রভাবিত না করে, সে জন্য স্বাধীন ডিস্ক-কপিতে অবস্থাগুলোর তুলনা করা হয়েছে;
- পর্যায়: বুটের পর 5 মিনিট, স্থিতিশীল হওয়ার জন্য 5 মিনিট, নিষ্ক্রিয় অবস্থায় 5 মিনিট;
- সংক্ষিপ্ত সিন্থেটিক লোড: 1, 4 এবং 8 থ্রেড, মেমরি লোড, বিরতিসহ লোড এবং মিশ্র অগ্রাধিকার।
পরিমাপে বাস্তব গেম, GPU লোড, ফিজিক্যাল হার্ডওয়্যার এবং দীর্ঘ সময়ের উইন্ডো (ঘণ্টা ও দিন) অন্তর্ভুক্ত ছিল না।
চারটি পর্যায় ও গেমিং পরিমাপসহ Ryzen 7 7800X3D-ভিত্তিক ফিজিক্যাল PC-তে আলাদা একটি সিরিজ «BoosterX: CS2-এ Windows ব্যাকগ্রাউন্ড ও FPS» নিবন্ধে প্রকাশিত হয়েছে। ভার্চুয়াল মেশিনের এই সিরিজের সঙ্গে সেই ফলাফল একত্র করা হয়নি।
প্রোটোকলটি «আমরা কীভাবে Windows নিয়ে গবেষণা করি»-এর সঙ্গে সামঞ্জস্যপূর্ণ:
- প্রতিটি পর্যায় ETW ট্রেসিং (Windows Performance Recorder, CPU, ডিস্ক, ফাইল ও নেটওয়ার্কের হালকা প্রোফাইল) এবং পারফরম্যান্স কাউন্টার দিয়ে রেকর্ড করা হয়েছে; ব্যবধান ছিল সিস্টেমের জন্য 5 সেকেন্ড এবং প্রসেস অনুযায়ী 15 সেকেন্ড;
- «বুটের পর» পর্যায়টি নিয়ন্ত্রিত রিবুট দিয়ে শুরু করা হয়েছিল এবং আপটাইম প্রায় এক মিনিট হলে গণনায় নেওয়া হয়েছিল;
- প্রতিটি ট্রেসে হারানো ইভেন্টের সংখ্যা যাচাই করা হয়েছে—উল্লিখিত সব উইন্ডোতে তা শূন্য;
- পর্যায়ের সীমানার মধ্যে কেবল পূর্ণ পাঁচ-সেকেন্ডের ব্যবধানের গড় নেওয়া হয়েছে (প্রতি পর্যায়ে 59টি ব্যবধান);
- 2 সিরিজে ভার্চুয়াল মেশিন স্লিপে চলে যাওয়ায় প্রথম «আগে» রানটি বাদ দেওয়া হয়েছে; পুনরায় চালানো রানটি ব্যবহার করা হয়েছে;
- লোড টেস্ট দুবার চালানো হয়েছে, মধ্যক দেখানো হয়েছে; CPU ব্যবহার চারটি vCPU অনুযায়ী স্বাভাবিকীকৃত।
«আগে» ও «পরে» একই Windows ইনস্টলেশনের দুটি অবস্থা: অপ্টিমাইজেশন প্রোফাইল প্রয়োগ করে «পরে» অবস্থা তৈরি করা হয়েছে, আর «আগে» হলো মূল অবস্থা। সেটিংসের পুরো সমষ্টি পরিবর্তন করা হয়েছে, তাই কোনো একক নিষ্ক্রিয়করণের পৃথক অবদান মূল্যায়ন করা হয়নি।
নিষ্ক্রিয় অবস্থা
Заголовок раздела «নিষ্ক্রিয় অবস্থা»সিরিজ 1 (2026-09-18) — সক্রিয় রক্ষণাবেক্ষণ ছাড়া স্থিতিশীল নিষ্ক্রিয় অবস্থা:
| মেট্রিক | আগে | পরে | পরিবর্তন |
|---|---|---|---|
| CPU ব্যবহার, % | 2,48 | 2,06 | −17 % |
| DPC + ISR, % CPU | 1,73 | 1,59 | −8 % |
| কনটেক্সট সুইচ, /সেকেন্ড | 469 | 381 | −19 % |
| প্রসেস (গড়) | 134,9 | 69,3 | −49 % |
| থ্রেড (গড়) | 1 444,6 | 738,7 | −49 % |
| সব প্রসেসের মোট CPU ব্যবহার, % | 1,22 | 1,06 | −13 % |
| উপলভ্য মেমরি, MB | 5 490 | 6 518 | +1 028 |
| ডিস্ক থেকে পড়া, KB/s | 22,6 | 24,4 | +8 % |
| ডিস্কে লেখা, KB/s | 311,3 | 262,1 | −16 % |
| নেটওয়ার্ক (গ্রহণ), KB/s | 132,6 | 2,2 | −98 % |
| নেটওয়ার্ক (প্রেরণ), KB/s | 43,2 | 4,7 | −89 % |
সিরিজ 2 (2026-09-19) — নিষ্ক্রিয় অবস্থার একই সময়সীমা, তবে «আগে» অবস্থায় Microsoft Defender-এর ব্যাকগ্রাউন্ড স্ক্যান চলছিল:
| মেট্রিক | আগে | পরে | পরিবর্তন |
|---|---|---|---|
| CPU ব্যবহার, % | 33,37 | 11,03 | −67 % |
| কনটেক্সট সুইচ, /সেকেন্ড | 3 737 | 291 | −92 % |
| প্রসেস (গড়) | 142,3 | 61,9 | −56 % |
| থ্রেড (গড়) | 1 494,7 | 637,1 | −57 % |
| উপলভ্য মেমরি, MB | 5 174 | 6 653 | +1 479 |
| ব্যবহৃত ফিজিক্যাল মেমরি, MB | 3 017 | 1 538 | −49 % |
| মেমরি কমিটমেন্ট (commit), MB | 2 617 | 1 249 | −52 % |
| Nonpaged pool, MB | 298,2 | 212,9 | −29 % |
| Paged pool, MB | 258,5 | 86,0 | −67 % |
| DPC, % CPU | 0,89 | 0,19 | −78 % |
| ডিস্ক থেকে পড়া, MB/s | 7,42 | 0,01 | −99,9 % |
| ডিস্কে লেখা, MB/s | 4,57 | 0,23 | −95,0 % |
2 সিরিজের নিষ্ক্রিয় অবস্থায় উভয় অবস্থাতেই নেটওয়ার্ক কার্যকলাপ প্রায় ছিল না (প্রতি সেকেন্ডে কয়েক দশ বাইট), তাই এর জন্য নেটওয়ার্কের সারি দেখানো হয়নি। সিরিজ দুটির পার্থক্য কোনো বিরোধ নয়, বরং ব্যাকগ্রাউন্ড কার্যকলাপেরই বৈশিষ্ট্য: Windows রক্ষণাবেক্ষণ চালালে ব্যাকগ্রাউন্ড উপাদান নিষ্ক্রিয় করে বেশি সাশ্রয় হয়; সময়সীমাটি আগে থেকেই শান্ত থাকলে সাশ্রয় কম।
বুটের পর প্রথম কয়েক মিনিট
Заголовок раздела «বুটের পর প্রথম কয়েক মিনিট»| মেট্রিক | সিরিজ 1 (আগে → পরে) | সিরিজ 2 (আগে → পরে) |
|---|---|---|
| CPU ব্যবহার, % | 3,42 → 2,59 | 14,62 → 11,88 |
| কনটেক্সট সুইচ, /সেকেন্ড | 1 114 → 600 | 1 257 → 393 |
| প্রসেস | 132 → 74 | 139 → 64 |
| থ্রেড | — | 1 719 → 746 |
| ব্যবহৃত ফিজিক্যাল মেমরি, MB | — | 2 821 → 1 581 |
| উপলভ্য মেমরি, MB | — | 5 370 → 6 610 |
| ডিস্ক থেকে পড়া, KB/s | — | 826 → 433 |
| ডিস্কে লেখা, KB/s | 634 → 418 | 709 → 298 |
| নেটওয়ার্ক (গ্রহণ), KB/s | — | 1,15 → ~0 |
ড্যাশ বোঝায়, এই সিরিজে ওই পর্যায়ের মেট্রিকটি রেকর্ড করা হয়নি।
গঠন ও মেমরি
Заголовок раздела «গঠন ও মেমরি»নিষ্ক্রিয় অবস্থায় ইনভেন্টরির স্ন্যাপশট (সিরিজ 1):
| আগে | পরে | |
|---|---|---|
| প্রসেস | 136 | 70 |
| থ্রেড | 1 679 | 842 |
| মোট working set, MB | 3 841 | 1 868 |
| মোট private bytes, MB | 1 524 | 660 |
অপ্টিমাইজেশনের আগে মেমরির সবচেয়ে বড় ব্যবহারকারী: অ্যান্টিভাইরাস প্রসেস MsMpEng.exe (257 MB), explorer.exe (213 MB), StartMenuExperienceHost (144 MB), msedge.exe (133 MB), SearchHost.exe (122 MB)। অপ্টিমাইজেশনের পরে তালিকার শীর্ষে ছিল explorer.exe (170 MB), msedgewebview2 (119 MB), SearchHost.exe (115 MB) এবং StartMenuExperienceHost (106 MB)।
উপলভ্য মেমরি বেড়েছে 1,0–1,5 GB, আর কমিটমেন্টের পরিমাণ কমেছে 52 %। এর মধ্যে কোনটি সত্যিই «মুক্ত» করা যায় এবং প্রসেসগুলোর working set-এর যোগফল কেন মুক্ত মেমরির সমান নয়, তা ব্যাখ্যা করা হয়েছে «Windows-এ বাস্তবে কত মেমরি মুক্ত করা যায়»-এ।
পূর্ণ লোডের অধীনে
Заголовок раздела «পূর্ণ লোডের অধীনে»সংক্ষিপ্ত সিন্থেটিক টেস্ট (সিরিজ 2, দুটি পুনরাবৃত্তির মধ্যক):
| পরিস্থিতি | থ্রুপুটের পরিবর্তন | CPU ব্যবহার: আগে / পরে |
|---|---|---|
| একটি থ্রেড | +5,4 % | 21,9 / 22,6 % |
| চারটি থ্রেড (পূর্ণ) | +0,19 % | 88,9 / 89,4 % |
| আটটি থ্রেড (পূর্ণ) | +0,50 % | 88,9 / 88,8 % |
| মেমরি লোড | +11,2 % | 84,8 / 87,5 % |
| বিরতিসহ (1 ms বিরতি) | +5,4 % | 64,3 / 67,7 % |
| মিশ্র অগ্রাধিকার | +8,5 % | 21,2 / 22,5 % |
| ব্যাকগ্রাউন্ড অগ্রাধিকার | +77,1 % | 38,8 / 65,2 % |
চার-থ্রেডের পূর্ণ লোডে, অপ্টিমাইজেশনের আগে ও পরে—দুই অবস্থাতেই কার্যকর প্রসেসটি চারটি vCPU-এর ক্ষমতার প্রায় 89 % পেয়েছে। ভার্চুয়াল মেশিনে বাকি ~11 %-কে দূর করা যায় এমন «Windows-শব্দ» বলা যায় না: গেস্ট ট্রেসিংয়ে হাইপারভাইজারের শিডিউলিং দেখা যায় না। কাজের থ্রেডগুলো সমানভাবে বণ্টিত ছিল (তাদের মধ্যে কাজের পরিমাণের পার্থক্য 0,994–0,997), কোনো থ্রেড কাজের সুযোগ থেকে বঞ্চিত হয়নি, আর অপ্টিমাইজেশনের পরে নিষ্ক্রিয় অবস্থায় CPU কিউ প্রায় ফাঁকা ছিল।
ব্যাকগ্রাউন্ড কার্যকলাপ কোথায় যায়
Заголовок раздела «ব্যাকগ্রাউন্ড কার্যকলাপ কোথায় যায়»«আগে» অবস্থায় ব্যাকগ্রাউন্ড কার্যকলাপের পরিমাপ করা উৎসগুলো:
- অ্যান্টিভাইরাস স্ক্যানিং — 2 সিরিজের সময়সীমায় প্রধান উৎস: পাঁচ মিনিটের নিষ্ক্রিয় সময়সীমায় প্রসেস
MsMpEng.exe212 CPU-সেকেন্ড ব্যবহার করেছে; - মূল অবস্থায় সার্চ সার্ভিস, SysMain সার্ভিস, টেলিমেট্রি, প্রিন্ট স্পুলার এবং অন্যান্য উপাদান চলছিল — অপ্টিমাইজেশন প্রোফাইল প্রায় 50টি ব্যাকগ্রাউন্ড সার্ভিস এবং 58টি নির্ধারিত টাস্ক নিষ্ক্রিয় অবস্থায় নিয়ে যায়;
- বুটের পর Windows আপডেট অর্কেস্ট্রেটর কার্যকলাপ চালায়।
ব্যাকগ্রাউন্ড উপাদান নিষ্ক্রিয় করলেও ব্যাকগ্রাউন্ড কার্যকলাপ পুরোপুরি দূর হয় না: অপ্টিমাইজ করা অবস্থায়ও অ্যাপ্লিকেশন সামঞ্জস্যতা মূল্যায়ন চলছিল (রক্ষণাবেক্ষণের সময়সীমায় প্রতি সেকেন্ডে প্রায় 3,7 ms CPU), আর স্থিতিশীল নিষ্ক্রিয় অবস্থায় অবশিষ্ট ব্যাকগ্রাউন্ড কার্যকলাপের যোগফল ছিল প্রতি সেকেন্ডে 4,8 ms CPU—চারটি vCPU-এর ক্ষমতার প্রায় 0,12 % (ট্রেসিং থেকে মাপা)।
যা নিশ্চিত হয়েছে
Заголовок раздела «যা নিশ্চিত হয়েছে»- পুনরায় পাওয়া গেছে (দুটি স্বাধীন সিরিজ): প্রসেসের সংখ্যা −49…−56 %, থ্রেড −49…−57 %, উপলভ্য মেমরি +1,0–1,5 GB।
- পরিমাপ করা হয়েছে (সিরিজ 2): নিষ্ক্রিয় অবস্থায় commit −52 %; নিষ্ক্রিয় অবস্থায় ব্যবহৃত ফিজিক্যাল মেমরি −49 % এবং বুটের পরের পর্যায়ে −44 %।
- পরিমাপ করা হয়েছে: নিষ্ক্রিয় অবস্থায় CPU ব্যবহার শান্ত সময়সীমায় −17 % এবং স্ক্যান চলার সময়সীমায় −67 %; কনটেক্সট সুইচ −19 % এবং −92 %; DPC −78 % (2 সিরিজের সময়সীমা); বুটের পর উভয় সিরিজেই কার্যকলাপ কম।
- পরিমাপ করা হয়েছে: CPU-তে পূর্ণ লোডের অধীনে থ্রুপুট বৃদ্ধি +0,19 % (4 থ্রেড) এবং +0,50 % (8 থ্রেড); আংশিক ও মিশ্র লোডে +5,4 থেকে +11,2 % পর্যন্ত।
- পরিমাপ করা হয়েছে: ব্যাকগ্রাউন্ড অগ্রাধিকার-শ্রেণির লোড 77,1 % দ্রুত হয়েছে—«আগে» অবস্থায় এটি Windows-এর নিজস্ব ব্যাকগ্রাউন্ড কাজের সঙ্গে প্রতিযোগিতা করছিল, যার মধ্যে অ্যান্টিভাইরাস স্ক্যানিংও ছিল।
- পর্যবেক্ষণ করা হয়েছে: ব্যাকগ্রাউন্ডের প্রধান উৎস হলো অ্যান্টিভাইরাস স্ক্যানিং, রক্ষণাবেক্ষণ ও সামঞ্জস্যতা-সংক্রান্ত টাস্ক; অপ্টিমাইজেশনের পরে অবশিষ্ট ব্যাকগ্রাউন্ড কার্যকলাপ প্রায় শূন্য, তবে শূন্য নয়।
যা নিশ্চিত হয়নি
Заголовок раздела «যা নিশ্চিত হয়নি»- বাস্তব গেমে FPS বৃদ্ধি, input lag বা frametime হ্রাস: মাপা হয়নি। সিন্থেটিক CPU টেস্ট GPU-সহ গেমের অনুকরণ করে না এবং গেমিংয়ের প্রভাব প্রমাণ করে না।
- প্রতিটি পৃথক নিষ্ক্রিয়করণের স্বতন্ত্র অবদান: পরিবর্তনের একটি সমষ্টি প্রয়োগ করা হয়েছিল।
- পরম মানগুলো ফিজিক্যাল হার্ডওয়্যার, অন্য বিল্ড এবং অন্য অপ্টিমাইজেশন প্রোফাইলে প্রয়োগ করা।
- দীর্ঘ সময়ের উইন্ডোতে স্থায়িত্ব: প্রতিটি পর্যায় ছিল 5 মিনিট; Windows-এর ব্যাকগ্রাউন্ড কাজ ঢেউয়ের মতো আসে, তাই «গড় দিন» মাপা হয়নি।
সীমাবদ্ধতা
Заголовок раздела «সীমাবদ্ধতা»- পরিমাপ ভার্চুয়াল মেশিনে করা হয়েছে। ভার্চুয়ালাইজেশন নিজস্ব DPC/ISR যোগ করে এবং হোস্টের শিডিউলিং আড়াল করে; ফিজিক্যাল হার্ডওয়্যারে পরম মান আলাদা হবে। একই পরিস্থিতিতে «আগে/পরে» তুলনার অনুপাত ও প্রভাবের দিক বজায় থাকে।
- ISR মেট্রিকটি টেবিল থেকে বাদ দেওয়া হয়েছে: ভার্চুয়াল মেশিনে PDH-এর ISR কাউন্টার ETW-এর interrupt handler-এর মানের সঙ্গে প্রায় 10 % অমিল দেখায় এবং সঠিক যোগফলে মেলে না।
- 2 সিরিজের «আগে» সময়সীমায় Defender-এর সক্রিয় স্ক্যান চলছিল, আর সময়সীমাগুলোর মধ্যে হোস্টের লোড আলাদা ছিল (গড়ে 44 % বনাম 24 %)। তাই মানগুলো নির্দিষ্ট সময়সীমার সঙ্গে সম্পর্কিত; দুটি সিরিজে প্রভাবের দিক নিশ্চিত হয়েছে।
- 1 সিরিজে নিষ্ক্রিয় পর্যায়ের কিছু অংশ ভার্চুয়াল মেশিনের প্রায় 26 সেকেন্ডের বাহ্যিক বিরতিতে বাধাগ্রস্ত হয়েছিল; পুনরায় চালু হওয়ার পর ক্যাপচার শেষ হয়েছে, কোনো ইভেন্ট হারায়নি।
- লোড টেস্টে দুটি পুনরাবৃত্তি ছিল: এটি বর্ণনামূলক পরিসংখ্যান, পরিসংখ্যানগত তাৎপর্য মূল্যায়ন করা হয়নি।
- নিষ্ক্রিয় অবস্থায় লাভের একটি অংশ Microsoft Defender-এর সুরক্ষা উপাদান নিষ্ক্রিয় করার সঙ্গে সম্পর্কিত। অ্যান্টিভাইরাস সুরক্ষা ছাড়া সিস্টেম ব্যবহার করা একটি সচেতন আপস, বিনা খরচের অপ্টিমাইজেশন নয়; এর মূল্য বুঝে সুরক্ষা নিষ্ক্রিয় করুন।
- পরিমাপের স্তর (ট্রেসিং ও কাউন্টার) নিজেও সামান্য ব্যাকগ্রাউন্ড লোড তৈরি করে; উভয় অবস্থাতেই তা উপস্থিত।
গবেষণা ও ব্যবহৃত টুলগুলো BoosterX-এর ডেভেলপারের, তাই ফলাফলে ডেভেলপারের সরাসরি স্বার্থ রয়েছে। পদ্ধতি ও প্রযোজ্যতার সীমা উপরে বর্ণিত হয়েছে; উন্মুক্ত ডেটা ও তালিকাভুক্ত সর্বজনীন উৎস থেকে সিদ্ধান্তগুলো যাচাই করা যায়।
ব্যবহারিক উপসংহার
Заголовок раздела «ব্যবহারিক উপসংহার»ব্যাকগ্রাউন্ডের শব্দ কমানো বাস্তব এবং দুবার পুনরায় পাওয়া গেছে: প্রসেস ও থ্রেডের সংখ্যা অর্ধেক, মেমরি কমিটমেন্ট অর্ধেক, আর নিষ্ক্রিয় অবস্থায় ডিস্ক ও নেটওয়ার্ক কার্যকলাপ এক ক্রম কম। এটি নিজেই উপকারী—সিস্টেমের সাড়া দেওয়া, ব্যাকগ্রাউন্ড কাজ, তাপমাত্রা, ফ্যানের শব্দ এবং ব্যাটারিতে চলার সময়ের জন্য—এবং এর জন্য FPS বৃদ্ধির প্রতিশ্রুতি দেওয়ার দরকার নেই।
যা আশা করা উচিত নয়: পূর্ণ লোডের অধীনে কর্মক্ষমতা বৃদ্ধি। CPU যদি ইতিমধ্যে ~89 % ক্ষমতায় কার্যকর কাজ করে, তাহলে ব্যাকগ্রাউন্ড কার্যকলাপ নিষ্ক্রিয় করে বাকি 11 % যোগ হবে না—ভার্চুয়াল মেশিনে সেই অংশ Windows-এর নয়। তুলনার সময় সিস্টেম কী কাজে ব্যস্ত, তার ওপর দৃশ্যমান প্রভাব নির্ভর করে: রক্ষণাবেক্ষণের সময়সীমায় পার্থক্য কয়েক গুণ, শান্ত সময়সীমায় মাঝারি।
সুপারিশ: অন্যের শতাংশের ওপর নির্ভর না করে নিজের কম্পিউটারে যেকোনো পরিবর্তনের আগে ও পরে ব্যাকগ্রাউন্ড কার্যকলাপ যাচাই করুন (Task Manager → «Performance» এবং «Processes», Resource Monitor)। লক্ষ্য যদি নির্দিষ্ট কোনো গেমে FPS হয়, তাহলে পরিবর্তনের আগে ও পরে সেটিই মাপুন।
অবস্থা পুনরুদ্ধার
Заголовок раздела «অবস্থা পুনরুদ্ধার»দুটি সিরিজই স্বাধীন ডিস্ক-কপিতে বিচ্ছিন্ন ভার্চুয়াল মেশিনে চালানো হয়েছিল; পরিমাপের পরে মেশিনগুলোকে মূল অবস্থায় ফিরিয়ে নেওয়া হয়েছিল। নিবন্ধটির জন্য পাঠককে কোনো সেটিং পরিবর্তন করতে হয় না, তাই ব্যবহারকারীর কম্পিউটারে আলাদা করে অবস্থা পুনরুদ্ধারের কোনো পদক্ষেপ দরকার নেই।
সর্বজনীন প্রাথমিক উৎস
Заголовок раздела «সর্বজনীন প্রাথমিক উৎস»- Microsoft: Windows Performance Recorder — পদ্ধতিতে ব্যবহৃত ETW ট্রেস রেকর্ড করার টুল; যাচাই করা হয়েছে 2026-09-20।
- Microsoft: About Event Tracing — ETW মডেল ও হারানো ইভেন্ট যাচাই; যাচাই করা হয়েছে 2026-09-20।
- Microsoft: Windows-এ Microsoft Defender Antivirus — Defender-এর প্রসেস ও সার্ভিস, যার মধ্যে
MsMpEng.exe-ও রয়েছে (Task Manager-এ «Antimalware Service Executable»); যাচাই করা হয়েছে 2026-09-20। - আমরা কীভাবে Windows নিয়ে গবেষণা করি — প্রমাণের স্তর ও পরিমাপের প্রোটোকল।
- Service Host ও Windows 11-এর ব্যাকগ্রাউন্ড উপাদান — Windows কীভাবে প্রসেস অনুযায়ী ব্যাকগ্রাউন্ড সার্ভিসগুলো রাখে।
- Windows-এ বাস্তবে কত মেমরি মুক্ত করা যায় — একই পরীক্ষার মেমরি নিয়ে বিস্তারিত বিশ্লেষণ।
- ডেস্কটপ বনাম সাইন-ইন স্ক্রিন — পরবর্তী আলোচনা: ব্যবহারকারীর সেশনের শব্দ কী দিয়ে তৈরি।
পরিবর্তনের ইতিহাস
Заголовок раздела «পরিবর্তনের ইতিহাস»- 2026-09-20: প্রথম প্রকাশনা — নিষ্ক্রিয় অবস্থার পরিমাপের দুটি স্বাধীন সিরিজ, বুটের পরের পর্যায়, ইনভেন্টরি ও লোড টেস্ট।
- 2026-09-20: সিরিজ অনুযায়ী ফলাফলের আরোপ স্পষ্ট করা হয়েছে (commit ও ব্যবহৃত ফিজিক্যাল মেমরি—শুধু 2 সিরিজ; প্রসেস −49…−56 %); স্বার্থের সংঘাত-সংক্রান্ত ডিসক্লেইমারটি প্রামাণ্য রূপে আনা হয়েছে।