خاموش حالت: آپٹیمائزیشن سے پہلے اور بعد میں Windows کا پس منظر
На этой странице
مختصر جواب
Заголовок раздела «مختصر جواب»Windows کے پسِ منظر کے اجزا بند کرنے سے واقعی بیکار حالت زیادہ پُرسکون ہو جاتی ہے: پیمائش کی دو آزاد سیریز میں عملوں کی تعداد 49–56 % کم ہوئی، بیکار حالت میں CPU کا استعمال 17–67 % کم ہوا، اور دوسری سیریز میں میموری کمٹ (commit) کی مقدار 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 کے آپٹیمائزیشن پروفائل کے اطلاق کے بعد (پیمائش کی تاریخوں پر دستیاب موجودہ build)؛
- پیمائش کی دو آزاد سیریز: 2026-09-18 اور 2026-09-19؛ حالتوں کا موازنہ ڈسک کی آزاد کاپیوں پر کیا گیا تاکہ پیمائشیں ایک دوسرے پر اثر انداز نہ ہوں؛
- مراحل: بوٹ کے بعد 5 منٹ، استحکام کے لیے 5 منٹ، بیکار حالت کے 5 منٹ؛
- مختصر مصنوعی بوجھ: 1، 4 اور 8 تھریڈز، میموری پر بوجھ، وقفوں والا بوجھ اور ترجیحات کے امتزاج۔
پیمائشوں میں حقیقی گیمز، GPU کا بوجھ، فزیکل ہارڈویئر اور طویل دورانیے (گھنٹے اور دن) شامل نہیں تھے۔
Ryzen 7 7800X3D والے فزیکل PC پر چار مراحل اور گیمنگ پیمائشوں کی ایک الگ سیریز مضمون «BoosterX: Windows کا پسِ منظر اور CS2 میں 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/سیکنڈ | 22,6 | 24,4 | +8 % |
| ڈسک پر لکھنا، KB/سیکنڈ | 311,3 | 262,1 | −16 % |
| نیٹ ورک (وصولی)، KB/سیکنڈ | 132,6 | 2,2 | −98 % |
| نیٹ ورک (ارسال)، KB/سیکنڈ | 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/سیکنڈ | 7,42 | 0,01 | −99,9 % |
| ڈسک پر لکھنا، MB/سیکنڈ | 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/سیکنڈ | — | 826 → 433 |
| ڈسک پر لکھنا، KB/سیکنڈ | 634 → 418 | 709 → 298 |
| نیٹ ورک (وصولی)، KB/سیکنڈ | — | 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 اضافہ ہوا، جبکہ کمٹ (commit) کی مقدار 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.exeنے بیکار حالت کے پانچ منٹ کے دورانیے میں 212 CPU سیکنڈ استعمال کیے؛ - اصل حالت میں سرچ سروس، SysMain سروس، ٹیلی میٹری، پرنٹ اسپولر اور دیگر اجزا چل رہے تھے — آپٹیمائزیشن پروفائل تقریباً 50 پسِ منظر کی سروسز اور 58 شیڈول شدہ ٹاسکس کو غیر فعال حالت میں منتقل کرتا ہے؛
- بوٹ کے بعد Windows Update کا آرکیسٹریٹر سرگرمی جاری رکھتا ہے۔
پسِ منظر کے اجزا بند کرنے سے پسِ منظر کی سرگرمی مکمل طور پر ختم نہیں ہوتی: آپٹیمائزڈ حالت میں ایپلیکیشن مطابقت کی جانچ جاری رہی (مینٹیننس کے دورانیے میں تقریباً 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 کے ساتھ گیم کی نقل نہیں کرتیں اور گیمنگ کے اثر کو ثابت نہیں کرتیں۔
- ہر انفرادی تبدیلی کا الگ اثر: تبدیلیوں کا ایک مجموعہ لاگو کیا گیا۔
- مطلق مقداروں کا فزیکل ہارڈویئر، دیگر builds اور دیگر آپٹیمائزیشن پروفائلز پر اطلاق۔
- طویل دورانیوں میں استحکام: ہر مرحلہ 5 منٹ کا تھا؛ Windows کا پسِ منظر کا کام وقفے وقفے سے بڑھتا ہے، اس لیے «اوسط دن» کی پیمائش نہیں کی گئی۔
- پیمائشیں ورچوئل مشین میں کی گئیں۔ ورچوئلائزیشن DPC/ISR میں اپنا حصہ ڈالتی ہے اور میزبان کی شیڈولنگ کو چھپا دیتی ہے؛ فزیکل ہارڈویئر پر مطلق مقداریں مختلف ہوں گی۔ یکساں حالات میں «پہلے/بعد» کے موازنے کا تناسب اور سمت برقرار رہتے ہیں۔
- ISR پیمانہ جدولوں سے خارج ہے: ورچوئل مشین میں PDH کا ISR کاؤنٹر، ETW کے ذریعے درج کردہ انٹرپٹ ہینڈلرز سے تقریباً 10 % مختلف ہے اور دونوں کا مجموعہ عین مطابق نہیں بنتا۔
- سیریز 2 کے «پہلے» والے دورانیے میں Defender کی فعال اسکیننگ شامل تھی، اور دورانیوں کے درمیان میزبان کا بوجھ مختلف تھا (اوسطاً 44 % بمقابلہ 24 %)۔ اس لیے مقداریں مخصوص دورانیوں سے متعلق ہیں؛ سمت کی تصدیق دو سیریز سے ہوئی۔
- سیریز 1 میں بیکار حالت کے مرحلے کا کچھ حصہ ورچوئل مشین کے تقریباً 26 سیکنڈ کے بیرونی وقفے سے منقطع ہوا؛ دوبارہ شروع ہونے کے بعد ریکارڈنگ مکمل ہوئی، کوئی ایونٹ ضائع نہیں ہوا۔
- بوجھ کی آزمائشوں کے دو رنز تھے: یہ وضاحتی اعدادوشمار ہیں، شماریاتی اہمیت کا جائزہ نہیں لیا گیا۔
- بیکار حالت میں حاصل ہونے والے فائدے کا کچھ حصہ Microsoft Defender کے حفاظتی اجزا بند کرنے سے متعلق ہے۔ اینٹی وائرس تحفظ کے بغیر سسٹم ایک سوچا سمجھا سمجھوتہ ہے، بے لاگ آپٹیمائزیشن نہیں؛ تحفظ بند کرنے سے پہلے اس کی قیمت سمجھ لیں۔
- پیمائش کی تہہ (ٹریس اور کاؤنٹرز) خود بھی پسِ منظر میں معمولی بوجھ پیدا کرتی ہے؛ یہ دونوں حالتوں میں موجود تھا۔
تحقیق اور استعمال کیے گئے ٹولز BoosterX کے ڈویلپر کی ملکیت ہیں، اس لیے ڈویلپر کو نتائج میں براہِ راست مفاد حاصل ہے۔ طریقۂ کار اور اطلاق کی حدود اوپر بیان کی گئی ہیں، اور نتائج کو کھلے ڈیٹا اور درج کردہ عوامی ذرائع سے جانچا جا سکتا ہے۔
عملی نتیجہ
Заголовок раздела «عملی نتیجہ»پسِ منظر کے شور میں کمی ایک حقیقی اثر ہے، جسے دو بار دوبارہ دیکھا گیا: عملوں اور تھریڈز کی تعداد آدھی، میموری کمٹ آدھا، اور بیکار حالت میں ڈسک اور نیٹ ورک کی سرگرمی ایک درجۂ مقدار کم۔ یہ بذاتِ خود مفید ہے — سسٹم کی جواب دہی، پسِ منظر کے ٹاسکس، درجۂ حرارت، پنکھوں کے شور اور بیٹری پر چلنے کے وقت کے لیے — اور اس کے لیے FPS کے وعدوں کی ضرورت نہیں۔
اس سے مکمل بوجھ کے تحت کارکردگی میں اضافے کی توقع نہ رکھیں۔ اگر CPU پہلے ہی مفید کام کے ساتھ اپنی گنجائش کے ~89 % پر چل رہا ہے تو پسِ منظر کی سرگرمی بند کرنے سے باقی 11 % نہیں ملیں گے — ورچوئل مشین میں وہ Windows کے حصے میں نہیں آتے۔ موازنے کے وقت سسٹم جتنا زیادہ مصروف ہو، نظر آنے والا اثر اتنا ہی بڑا ہوتا ہے: مینٹیننس کے دورانیے میں فرق کئی گنا ہوتا ہے، جبکہ پُرسکون دورانیے میں معتدل ہوتا ہے۔
تجویز: اپنے کمپیوٹر پر کسی بھی تبدیلی سے پہلے اور بعد میں پسِ منظر کی سرگرمی کا جائزہ لیں (Task Manager → «کارکردگی» اور «عمل»، 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 %)؛ مفادات کے ٹکراؤ سے متعلق دستبرداری کو معیاری عبارت کے مطابق کیا گیا۔
