BoosterX: aktywność w tle Windows i FPS w CS2
Na tej stronie
Porównanie czterech etapów na jednym komputerze. Po kolejnym zastosowaniu optymalizacji BoosterX aktywność w tle Windows spadła, a średni FPS w wybranym benchmarku CS2 wzrósł o 2,23–2,96% względem przygotowanego systemu Clean. Advanced Advanced zapewnił najwyższy średni FPS, a Expert Hardcore — najwyższy P1 i najniższą aktywność w zarejestrowanym czasie bezczynności.
Pomiary przeprowadził deweloper BoosterX. Wynik dotyczy jednej serii na wskazanej konfiguracji testowej. W obliczeniach uwzględniono wszystkie osiem przebiegów FPS i pełne pięciominutowe okna WPR.
Wyniki WPR · Wyniki CS2 · Metodyka · Pobierz dane źródłowe
Co sprawdzano
Dział zatytułowany „ Co sprawdzano”Cel: sprawdzić, jak zmieniają się aktywność w tle Windows i wydajność w ustalonym scenariuszu CS2 przy kolejnym przechodzeniu przez etapy Clean → Safe Advanced → Advanced Advanced → Expert Hardcore.
WPR i CapFrameX odpowiadają na różne pytania. WPR pokazuje aktywność systemu po zalogowaniu i w czasie bezczynności. CapFrameX mierzy odstępy między klatkami podczas obciążenia gry. Kilkukrotne zmniejszenie obciążenia CPU w tle samo w sobie nie oznacza takiego samego wzrostu FPS.
Konfiguracja testowa i przygotowanie
Dział zatytułowany „ Konfiguracja testowa i przygotowanie”| Parametr | Warunki serii |
|---|---|
| Data pomiarów | 24 października 2026 roku |
| CPU | AMD Ryzen 7 7800X3D, 8 rdzeni / 16 wątków |
| GPU | NVIDIA GeForce RTX 5070, sterownik 617.42 |
| RAM | 32 GB, 2 × 16 GB DDR5-6000 |
| Płyta / BIOS | ASRock B850 Riptide WiFi / 4.20 |
| Windows | Windows 11 Pro 26H2, kompilacja 26300.9711 |
| BoosterX | 2.4.2.4, kompilacja Debug; nie zachowano skrótu użytego pliku binarnego |
| CapFrameX | 1.8.6.2 |
| CS2 | CS2 FPS BENCHMARK DUST2, Workshop ID 3240880604 |
| Grafika | 1280×960, ustawienie Low, FidelityFX wyłączone, Reflex włączone, fps_max 0 |
| Pozostałe ustawienia | ReBAR, Game Mode i HAGS włączone; CapFrameX określił tryb prezentacji jako Fullscreen Optimized or Borderless |
| Zasilanie | Clean, Safe i Advanced: „Zrównoważony”; Expert Hardcore: PowerX v2.1 |
Przygotowanie: czysta instalacja Windows, wszystkie aktualizacje, Steam, Spotify i sterowniki chipsetu AMD. Pliki CS2 przeniesiono z innego dysku. Sterownik karty graficznej usunięto za pomocą DDU i zainstalowano ponownie przy użyciu narzędzia instalacji niestandardowej z ograniczonym zestawem składników NVIDIA. Dokładny zestaw składników i wersja sterownika chipsetu nie zostały osobno zapisane. Przed pomiarem bazowym nie wprowadzono innych ręcznych zmian.
Oznacza to, że Clean oznacza tutaj przygotowany system przed zastosowaniem BoosterX, już z aplikacjami i sterownikami. Nie jest to Windows bezpośrednio po pierwszym ekranie instalacji. W ETL Clean widoczna jest również aktywność OneDrive i składników Edge.
Według danych z czujników średnia częstotliwość CPU Max podczas przebiegów FPS wynosiła około 5035–5043 MHz, a GPU około 2927–2930 MHz. Częstotliwości się zmieniały: seria nie była przeprowadzana przy stałych zegarach CPU/GPU. CPU Max nie jest pomiarem efektywnej częstotliwości każdego rdzenia. Ustawienia PBO i Curve Optimizer nie zostały zapisane.
Metodyka
Dział zatytułowany „ Metodyka”Cztery stany zastosowano kolejno na jednej instalacji Windows. Na każdym etapie najpierw wykonywano cykl WPR, a następnie test FPS. Między etapami nie przywracano obrazu Clean; zmiany się kumulowały. W zestawie zachowała się nieukończona próba WPR Expert Hardcore bez ETL. W podsumowaniu uwzględniono następny, ukończony zapis. Jeden przebieg FPS Expert Hardcore wykonano przed tym ukończonym zapisem WPR, a drugi po nim.
WPR: pięć minut od rozpoczęcia zapisu przy logowaniu do systemu, pięć minut stabilizacji, a następnie pięć minut bezczynności. Rejestrowano lekkie profile aktywności CPU, dysku, plików i sieci. Obliczenia wykonano bezpośrednio z ETL, między znacznikami początku i końca każdej fazy. Czas trwania każdego okna różni się od 300 sekund o mniej niż 0,02 sekundy. Nagłówki wszystkich ośmiu plików ETL wskazują zerową liczbę utraconych zdarzeń i buforów.
Początek pierwszej fazy przypadał mniej więcej na 15–23 sekundę po uruchomieniu Windows. Ten test nie mierzył czasu uruchamiania systemu operacyjnego. Metryki końcowe przeliczono z ETL.
CS2: po dwa przebiegi trwające około 105 sekund na każdy etap. Użyto automatycznego scenariusza mapy. Rejestrowanie CapFrameX uruchamiano ręcznie skrótem klawiszowym, mniej więcej w tym samym punkcie odniesienia. Początki nie były synchronizowane klatka po klatce. Dwa pliki z błędną nazwą procesu infinst.exe również dotyczą testu CS2. W archiwum zachowano oryginalne nazwy i zawartość JSON.
Nie zapisano dokładnej kompilacji CS2, wersji zawartości mapy w chwili nagrania, osobnej wartości MSAA ani czasu wstępnego rozgrzewania. Obecna wersja mapy w Workshop może różnić się od użytej. Porównanie dotyczy tej mapy, a nie FPS w meczu rankingowym: autorzy mapy osobno zwracają uwagę na różnicę między lokalną symulacją a grą na serwerze.
WPR: aktywność Windows w tle
Dział zatytułowany „ WPR: aktywność Windows w tle”| Wskaźnik | Clean | Safe Advanced | Advanced Advanced | Expert Hardcore |
|---|---|---|---|---|
| Po zalogowaniu: zapis z pierwszych 5 minut | ||||
| Średnie użycie CPU, % | 1,488Baza | 0,411Δ −1,077 p.p.−72,37% | 0,314Δ −1,174 p.p.−78,91% | 0,283Δ −1,205 p.p.−80,99% |
| Szczytowe użycie CPU w przedziale ok. 1 s, % | 30,60Baza | 14,30Δ −16,30 p.p.−53,27% | 11,36Δ −19,24 p.p.−62,89% | 6,44Δ −24,16 p.p.−78,95% |
| Szacowany czas CPU, rdzeń·s | 71,42Baza | 19,73Δ −51,68−72,37% | 15,06Δ −56,35−78,91% | 13,58Δ −57,84−80,98% |
| Przełączenia kontekstu / s | 5781,8Baza | 1330,6Δ −4451,2−76,99% | 1006,3Δ −4775,4−82,59% | 763,3Δ −5018,5−86,80% |
| Przełączenia kontekstu, łącznie | 1 734 523Baza | 399 198Δ −1 335 325−76,99% | 301 900Δ −1 432 623−82,59% | 229 000Δ −1 505 523−86,80% |
| Przejścia wątków do stanu Ready / s | 3692,2Baza | 817,9Δ −2874,2−77,85% | 614,7Δ −3077,5−83,35% | 455,7Δ −3236,5−87,66% |
| Procesy na końcu okna | 148Baza | 96Δ −52−35,14% | 92Δ −56−37,84% | 67Δ −81−54,73% |
| Uruchomienia procesów w oknie | 113Baza | 27Δ −86−76,11% | 18Δ −95−84,07% | 16Δ −97−85,84% |
| Wątki na końcu okna | 2566Baza | 1718Δ −848−33,05% | 1643Δ −923−35,97% | 1349Δ −1217−47,43% |
| Uruchomienia wątków w oknie | 2833Baza | 1030Δ −1803−63,64% | 832Δ −2001−70,63% | 683Δ −2150−75,89% |
| Suma zestawów roboczych procesów¹, MiB | 5054,5Baza | 3283,6Δ −1770,9−35,04% | 2954,5Δ −2099,9−41,55% | 2234,4Δ −2820,0−55,79% |
| Suma pamięci commit procesów¹, MiB | 2589,9Baza | 1685,1Δ −904,8−34,93% | 1586,2Δ −1003,7−38,76% | 1195,6Δ −1394,3−53,84% |
| Uchwyty procesów¹ | 66 187Baza | 43 247Δ −22 940−34,66% | 40 520Δ −25 667−38,78% | 30 987Δ −35 200−53,18% |
| DPC / s | 981,7Baza | 347,4Δ −634,3−64,61% | 306,4Δ −675,4−68,79% | 204,2Δ −777,5−79,20% |
| Przerwania sprzętowe (ISR) / s | 420,1Baza | 120,4Δ −299,7−71,34% | 102,7Δ −317,4−75,56% | 92,3Δ −327,8−78,03% |
| Hard faults w oknie² | 16 251Baza | 9661Δ −6590−40,55% | 6049Δ −10 202−62,78% | 5271Δ −10 980−67,57% |
| Odczyt z dysku, MiB | 920,36Baza | 295,67Δ −624,69−67,87% | 237,00Δ −683,36−74,25% | 218,96Δ −701,40−76,21% |
| Zapis na dysk, MiB | 758,41Baza | 123,43Δ −634,98−83,73% | 89,13Δ −669,28−88,25% | 66,27Δ −692,13−91,26% |
| W tym zapis plików WPR³, MiB | 591,76Baza | 85,00Δ −506,76−85,64% | 62,00Δ −529,76−89,52% | 42,00Δ −549,76−92,90% |
| Operacje odczytu z dysku | 29 124Baza | 16 718Δ −12 406−42,60% | 13 234Δ −15 890−54,56% | 12 391Δ −16 733−57,45% |
| Operacje zapisu na dysku | 13 298Baza | 3118Δ −10 180−76,55% | 2157Δ −11 141−83,78% | 1588Δ −11 710−88,06% |
| Czas trwania okna, s | 300,000 | 300,018 | 300,003 | 300,015 |
| Bezczynność: ostatnie 5 minut cyklu | ||||
| Średnie użycie CPU, % | 1,238Baza | 1,694Δ +0,456 p.p.+36,86% | 0,337Δ −0,901 p.p.−72,77% | 0,183Δ −1,055 p.p.−85,25% |
| Szczytowe użycie CPU w przedziale ok. 1 s, % | 12,17Baza | 17,74Δ +5,57 p.p.+45,79% | 6,47Δ −5,70 p.p.−46,86% | 6,25Δ −5,92 p.p.−48,64% |
| Szacowany czas CPU, rdzeń·s | 59,41Baza | 81,31Δ +21,90+36,86% | 16,18Δ −43,23−72,77% | 8,76Δ −50,64−85,25% |
| Przełączenia kontekstu / s | 1944,9Baza | 2061,6Δ +116,7+6,00% | 806,9Δ −1138,0−58,51% | 336,5Δ −1608,4−82,70% |
| Przełączenia kontekstu, łącznie | 583 440Baza | 618 477Δ +35 037+6,01% | 242 071Δ −341 369−58,51% | 100 967Δ −482 473−82,69% |
| Przejścia wątków do stanu Ready / s | 1208,0Baza | 1272,0Δ +64,0+5,30% | 522,9Δ −685,1−56,72% | 200,3Δ −1007,7−83,42% |
| Procesy na końcu okna | 153Baza | 101Δ −52−33,99% | 90Δ −63−41,18% | 64Δ −89−58,17% |
| Uruchomienia procesów w oknie | 19Baza | 168Δ +149+784,21% | 6Δ −13−68,42% | 5Δ −14−73,68% |
| Wątki na końcu okna | 2388Baza | 1678Δ −710−29,73% | 1412Δ −976−40,87% | 1189Δ −1199−50,21% |
| Uruchomienia wątków w oknie | 1200Baza | 2321Δ +1121+93,42% | 541Δ −659−54,92% | 333Δ −867−72,25% |
| Suma zestawów roboczych procesów¹, MiB | 5150,6Baza | 3477,7Δ −1672,9−32,48% | 2890,6Δ −2260,0−43,88% | 2202,8Δ −2947,8−57,23% |
| Suma pamięci commit procesów¹, MiB | 2847,4Baza | 1796,3Δ −1051,1−36,91% | 1587,9Δ −1259,5−44,23% | 1223,9Δ −1623,5−57,02% |
| Uchwyty procesów¹ | 68 628Baza | 45 867Δ −22 761−33,17% | 39 888Δ −28 740−41,88% | 30 597Δ −38 031−55,42% |
| DPC / s | 1210,5Baza | 277,5Δ −933,0−77,08% | 216,7Δ −993,7−82,09% | 108,8Δ −1101,7−91,01% |
| Przerwania sprzętowe (ISR) / s | 922,1Baza | 86,5Δ −835,6−90,62% | 64,3Δ −857,8−93,03% | 46,8Δ −875,3−94,93% |
| Hard faults w oknie² | 636Baza | 5258Δ +4622+726,73% | 1040Δ +404+63,52% | 1203Δ +567+89,15% |
| Odczyt z dysku, MiB | 12,90Baza | 105,32Δ +92,42+716,28% | 81,50Δ +68,60+531,64% | 9,83Δ −3,07−23,78% |
| Zapis na dysk, MiB | 214,57Baza | 317,84Δ +103,27+48,13% | 86,97Δ −127,60−59,47% | 31,03Δ −183,54−85,54% |
| W tym zapis plików WPR³, MiB | 164,00Baza | 172,00Δ +8,00+4,88% | 72,00Δ −92,00−56,10% | 15,00Δ −149,00−90,85% |
| Operacje odczytu z dysku | 634Baza | 5281Δ +4647+732,97% | 4241Δ +3607+568,93% | 836Δ +202+31,86% |
| Operacje zapisu na dysku | 5690Baza | 2410Δ −3280−57,64% | 1250Δ −4440−78,03% | 1783Δ −3907−68,66% |
| Czas trwania okna, s | 299,986 | 299,999 | 300,006 | 300,016 |
Pod każdą wartością pokazano Δ względem Clean w tej samej fazie: różnicę bezwzględną w jednostkach danego wiersza i zmianę względną w procentach. Dla obciążenia CPU różnicę bezwzględną podano w punktach procentowych (p.p.). Minus oznacza spadek wskaźnika, plus — wzrost; czas trwania okna podano bez delty. Wzory: Δ = этап − Clean, Δ% = (этап / Clean − 1) × 100.
CPU obliczono na podstawie próbek CPU Usage (Sampled), z uwzględnieniem czasu trwania przedziałów i uśrednieniem dla 16 procesorów logicznych. Szacowany czas CPU jest równy średniemu obciążeniu × czasowi trwania okna × 16 / 100. Szczyt obliczono z przedziałów trwających około jednej sekundy; skrajne przedziały mogą być krótsze. Zdarzenia zliczono w pełnym oknie; procesy i wątki odnoszą się do jego końca, bez Idle. Uruchomienia uwzględniają ponowne tworzenie tego samego procesu.
¹ Pamięć i uchwyty: zrzut liczników procesów po zakończeniu ETL, po 0,28–0,65 s od znacznika końcowego. Dokładne przesunięcie zapisano w JSON. Suma zestawów roboczych wielokrotnie uwzględnia współdzielone strony i nie jest równa zajętej pamięci fizycznej RAM. Commit procesów pokazuje przydzieloną pamięć wirtualną, której obsługę musi zapewnić RAM lub plik stronicowania; nie jest to ilość faktycznie zapisana w pliku stronicowania. Sumy te nie opisują całej pamięci jądra, sterowników i pamięci podręcznej plików.
² Hard faults oznaczają wczytanie z dysku strony nieobecnej w RAM, w tym stron plików. Nie są to sprzętowe błędy pamięci. DPC i ISR pokazują częstotliwość zdarzeń, a nie opóźnienie wejścia ani czas ich obsługi.
³ Zapis WPR wyodrębniono na podstawie nazw plików rejestratorów. Jest już uwzględniony w całkowitym zapisie na dysk. Metryki dysku obejmują działanie narzędzia pomiarowego i nie są czystą oceną obciążenia aplikacji.
W porównaniu Clean i Expert Hardcore próbkowane obciążenie CPU po zalogowaniu spadło około 5,3 raza, a w czasie bezczynności 6,8 raza. Liczba przełączeń kontekstu w czasie bezczynności spadła około 5,8 raza, a liczba procesów na końcu okna: 153 → 64. Są to relacje między konkretnymi zmierzonymi metrykami, a nie jeden współczynnik „przyspieszenia Windows”.
Dlaczego Safe bardziej obciążał system w czasie bezczynności
Dział zatytułowany „ Dlaczego Safe bardziej obciążał system w czasie bezczynności”W ostatniej minucie bezczynności w Safe działały mscorsvw.exe i ngen.exe. Na mscorsvw.exe przypadło około 56,4 sekundy procesora. Średnie obciążenie CPU w kolejnych minutach: 0,40 → 0,20 → 0,19 → 0,19 → 7,49%. W rezultacie całe okno było bardziej obciążone niż Clean, mimo że przez pierwsze cztery minuty aktywność była mniejsza.
Ten skok zachowano w głównej tabeli. Na podstawie jednej serii przeprowadzonej w ustalonej kolejności nie można oddzielić trwałego efektu trybu od jednorazowych zadań w tle i zmian stanu Windows w czasie.
Jak interpretować wskaźniki pamięci i dysku
Dział zatytułowany „ Jak interpretować wskaźniki pamięci i dysku”Całkowity zapis na dysk obejmuje zapis samego WPR. Na przykład w czasie bezczynności Clean z 214,57 MiB zapisu 164 MiB przypadło bezpośrednio na pliki rejestratorów WPR. Tę część wyodrębniono w tabeli w osobnym wierszu. Folder testowy znajdował się w OneDrive; wpływu synchronizacji nie wyodrębniono osobno. W tej publikacji nie porównuje się szybkości sieci ani zużycia energii.
CS2: FPS i czas klatki
Dział zatytułowany „ CS2: FPS i czas klatki”| Wskaźnik | Clean | Safe Advanced | Advanced Advanced | Expert Hardcore |
|---|---|---|---|---|
| Średni FPS | 888,29Baza | 911,19Δ +22,91+2,58% | 914,56Δ +26,28+2,96% | 908,08Δ +19,79+2,23% |
| P1 FPS | 296,73Baza | 304,42Δ +7,69+2,59% | 308,55Δ +11,82+3,98% | 312,15Δ +15,42+5,20% |
| P0,1 FPS | 259,15Baza | 265,90Δ +6,76+2,61% | 260,28Δ +1,13+0,44% | 264,29Δ +5,14+1,98% |
| 1% low: średnia z wolnych klatek, FPS | 275,50Baza | 283,63Δ +8,14+2,95% | 283,41Δ +7,91+2,87% | 288,21Δ +12,71+4,61% |
| Średni czas klatki, ms | 1,126Baza | 1,097Δ −0,028−2,51% | 1,093Δ −0,032−2,87% | 1,101Δ −0,025−2,18% |
| P99 czasu klatki, ms | 3,370Baza | 3,285Δ −0,085−2,53% | 3,241Δ −0,129−3,84% | 3,204Δ −0,167−4,95% |
| Średnia różnica między sąsiednimi klatkami, ms | 0,351Baza | 0,338Δ −0,013−3,64% | 0,335Δ −0,016−4,53% | 0,329Δ −0,022−6,30% |
| Średni FPS: zakres z dwóch przebiegów | 884,85 – 891,72 | 908,79 – 913,59 | 914,55 – 914,57 | 907,57 – 908,59 |
Advanced Advanced zapewnił najwyższy średni FPS: 914,56 wobec 888,29 w Clean, +2,96%. Expert Hardcore osiągnął nieco niższy średni FPS, ale najwyższy P1: 312,15 wobec 296,73, +5,20%. Najbardziej agresywny etap nie okazał się najlepszy pod każdym względem.
Średni FPS każdego przebiegu jest równy 1000 / среднее время кадра в мс. P1 jest równy 1000 / P99 времени кадра; P99 oblicza się przez interpolację liniową posortowanych klatek. Wyniki etapu są średnią z dwóch pomiarów. Pod wartościami pokazano deltę bezwzględną i względną względem Clean. W przypadku FPS więcej oznacza szybciej, a w przypadku czasu klatki — szybciej oznacza mniej. Wiersz 1% low obliczono osobno jako 1000 / среднее время самых медленных 1% кадров i nie jest równy P1.
Wszystkie osiem przebiegów i długie klatki
| Etap / przebieg | Klatek | Średni FPS | P1 FPS | P99, ms | Najdłuższa klatka, ms |
|---|---|---|---|---|---|
| Clean / 1 | 93 631 | 891,72 | 299,70 | 3,337 | 11,956 |
| Clean / 2 | 92 911 | 884,85 | 293,75 | 3,404 | 12,453 |
| Safe Advanced / 1 | 95 928 | 913,59 | 306,00 | 3,268 | 10,488 |
| Safe Advanced / 2 | 95 424 | 908,79 | 302,84 | 3,302 | 7,385 |
| Advanced Advanced / 1 | 96 030 | 914,55 | 307,77 | 3,249 | 11,177 |
| Advanced Advanced / 2 | 96 031 | 914,57 | 309,32 | 3,233 | 8,448 |
| Expert Hardcore / 1 | 95 295 | 907,57 | 310,07 | 3,225 | 9,144 |
| Expert Hardcore / 2 | 95 403 | 908,59 | 314,23 | 3,182 | 8,894 |
Wszystkie odstępy między klatkami są dodatnie, a ich kolejność czasowa jest monotoniczna. Długie klatki zachowano. Klatki nie są niezależnymi powtórzeniami eksperymentu: wykonano tylko dwa przebiegi FPS na etap. Zakres w tabeli pokazuje rozrzut tych dwóch przebiegów, a nie przedział ufności.
Średnie obciążenie GPU wynosiło około 74–76%, a szczytowe dochodziło do 95–96%. Dane te nie pozwalają stwierdzić, że każda część scenariusza była ograniczona wyłącznie przez CPU. Pole PcLatency z CapFrameX nie jest używane jako fizyczne opóźnienie „ruch myszy → światło ekranu”.
Frametime Variance: równomierność klatek
Dział zatytułowany „ Frametime Variance: równomierność klatek”Zastosowano zasadę z karty Variances w CapFrameX: wartość bezwzględna różnicy czasu dwóch sąsiednich klatek |tᵢ − tᵢ₋₁|, w milisekundach. Pary podzielono na pięć przedziałów: <2, 2–<4, 4–<8, 8–<12 i ≥12 мс. Jest to wskaźnik różnic między sąsiednimi klatkami; nie oblicza się tu wariancji statystycznej w ms². Granice przedziałów sprawdzono w kodzie źródłowym CapFrameX v1.8.6.
W Expert Hardcore udział par z różnicą od 2 ms wynosi 4,091% wobec 5,879% w Clean. To −1,787 p.p., czyli −30,4% względem Clean. W Safe Advanced spadek wynosi 18,0%, a w Advanced Advanced 26,1%. Te wartości procentowe dotyczą udziału różnic między sąsiednimi klatkami od 2 ms, a nie wzrostu FPS ani celności.
| Różnica między sąsiednimi klatkami | Clean | Safe Advanced | Advanced Advanced | Expert Hardcore |
|---|---|---|---|---|
| <2 ms | 94,1214% | 95,1774%Δ +1,0561 p.p. | 95,6581%Δ +1,5367 p.p. | 95,9087%Δ +1,7873 p.p. |
| 2–<4 ms | 5,8540% | 4,8038%Δ −1,0502 p.p. | 4,3226%Δ −1,5313 p.p. | 4,0693%Δ −1,7847 p.p. |
| 4–<8 ms | 0,0166% | 0,0162%Δ −0,0004 p.p. | 0,0172%Δ +0,0006 p.p. | 0,0210%Δ +0,0044 p.p. |
| 8–<12 ms | 0,0075% | 0,0026%Δ −0,0049 p.p. | 0,0021%Δ −0,0054 p.p. | 0,0010%Δ −0,0065 p.p. |
| ≥12 ms | 0,0005% | 0,0000%Δ −0,0005 p.p. | 0,0000%Δ −0,0005 p.p. | 0,0000%Δ −0,0005 p.p. |
Dla każdego etapu połączono liczniki par z dwóch przebiegów, bez łączenia ostatniej klatki jednego przebiegu z pierwszą klatką drugiego. Mianownik jest równy sumie N − 1 dla obu przebiegów. Dlatego udziały są ważone liczbą par, w przeciwieństwie do średniej z dwóch wartości FPS. W JSON i CSV zapisano dokładne liczby; w tabeli udziały zaokrąglono do czterech miejsc po przecinku. CapFrameX zaokrągla je wcześniej, dlatego ostatnie wyświetlane cyfry mogą się różnić.
Największy spadek dotyczy przedziału 2–<4 ms. Udział różnic 4–<8 ms w Expert Hardcore jest nieco wyższy niż w Clean: 0,0210% wobec 0,0166%. Zachowano wszystkie przedziały, w tym rzadkie różnice. Na podstawie dwóch przebiegów nie można ustalić powtarzalności tej zmiany.
Co to oznacza dla celowania: w tym benchmarku odstępy między klatkami stały się bardziej równomierne przy progu 2 ms. Możliwa korzyść dla płynności wizualnej ruchu celownika pozostaje przypuszczeniem: zapis odstępów między klatkami nie mierzy celności, ruchu myszy ani opóźnienia do pojawienia się obrazu. Na podstawie tej serii nie można obiecywać „znacznie lepszego celowania”.
Wnioski i ograniczenia wyniku
Dział zatytułowany „ Wnioski i ograniczenia wyniku”W tej serii przeprowadzonej w ustalonej kolejności odnotowano spadek aktywności w tle po zalogowaniu do systemu. W wybranym scenariuszu CS2 wszystkie trzy kolejne etapy zapewniły wyższy średni FPS niż przygotowany system Clean. Praktyczny wynik na tej konfiguracji testowej: około 2–3% średniego FPS, przy czym Advanced i Expert Hardcore mają różne mocne strony.
Badanie nie określa wpływu poszczególnych ustawień, uniwersalnej wielkości wzrostu, czasu uruchamiania Windows ani fizycznego opóźnienia wejścia. Expert Hardcore obejmuje zmianę planu zasilania, dlatego porównywany jest cały etap. Sama mniejsza liczba procesów nie jest miarą wydajności w grach.
Ograniczenia: jeden komputer, ustalona kolejność etapów, jeden ukończony zapis WPR na etap, dwa przebiegi FPS, ręczne rozpoczęcie przechwytywania, kompilacja Debug bez zapisanego skrótu pliku binarnego. Nie oddzielono wpływu kolejności, rozgrzewania pamięci podręcznej i obsługi w tle od optymalizacji. W czasie bezczynności Clean uruchomiono też na krótko Menedżera zadań; zachowano całe okno bez wycinania fragmentu. W tej serii nie przeprowadzono niezależnego powtórzenia ani kontrolnego przywrócenia Clean.
Antywirus i FPS
Dział zatytułowany „ Antywirus i FPS”Nie zaleca się wyłączania antywirusa w celu zwiększenia FPS. W tej serii porównuje się całe zestawy zmian: nie przeprowadzono osobnego testu z jedną zmienną „ochrona włączona / wyłączona”. Dlatego seria nie dowodzi, że antywirus nie ma żadnego wpływu na FPS, ani nie mierzy osobno oszczędności pamięci po jego wyłączeniu.
Microsoft zaleca pozostawienie włączonej ochrony w czasie rzeczywistym. W przypadku zauważalnego obciążenia dostępna jest analiza wydajności Microsoft Defender, która pozwala znaleźć konkretną przyczynę.
Przywracanie stanu
Dział zatytułowany „ Przywracanie stanu”Przywrócenia stanu początkowego po Expert Hardcore nie sprawdzano w ramach tych pomiarów. Aby powtórzyć test z niezależnymi stanami, należy przywracać wcześniej przygotowany obraz Clean i dokumentować przywrócenie. Ogólne ograniczenia cofania zmian opisano w granicach przywracania BoosterX.
Dane źródłowe i ponowne obliczenia
Dział zatytułowany „ Dane źródłowe i ponowne obliczenia”8 ETL · 8 CapFrameX JSON · tabele, wykresy i skrypty do ponownych obliczeń. Aby wyświetlić wyniki, otwórz README.html w archiwum. Oryginalne zapisy zachowano bez zmian. Dwa pliki o nazwie infinst.exe również należą do testu CS2.
SHA-256 archiwum7f20104f7eb46428e5e4f383515653b1320827be39fc171d1b5590210d0fbcdd
WPR, CSV · Wszystkie przebiegi FPS, CSV · Frametime Variance, CSV · Obliczenia, JSON · Skrypt do ponownych obliczeń
W jednym archiwum zebrano katalogi źródłowe czterech ukończonych etapów WPR, nieukończoną próbę Expert Hardcore, osiem oryginalnych plików JSON CapFrameX, użyte skrypty zapisu, metodykę, tabele, wykresy i kod źródłowy do ponownego przeliczenia. Nie uwzględniono starszych testów smoke ani powielających je archiwów pomocniczych. Obecność starego statusu weryfikacji w katalogach źródłowych nie zmienia przedstawionych tu obliczeń z ETL.
Do samodzielnej analizy ETL potrzebny jest Windows Performance Toolkit; do analizy źródłowych zapisów z gry można użyć CapFrameX. Skrypt analysis/analyze.py korzysta z Python 3 i WPT 10+, nie rozpoczyna zapisu ani nie zmienia systemu. Instrukcje znajdują się w README.html. Sumy kontrolne pozwalają sprawdzić, czy pliki pozostały niezmienione; nie potwierdzają warunków przeprowadzenia eksperymentu.
Ślady systemowe zachowano w postaci źródłowej: zawierają informacje techniczne o testowanej instalacji, w tym procesy, lokalne ścieżki i identyfikatory systemowe. Archiwum nie jest deklarowane jako zanonimizowane. Nie zawiera kodu źródłowego aplikacji BoosterX ani zewnętrznych plików wykonywalnych.
Źródła i historia
Dział zatytułowany „ Źródła i historia”- Oryginalne zapisy z tej serii i skrypt do ponownego przeliczenia są dostępne powyżej.
- CS2 FPS BENCHMARK DUST2: opis i ograniczenia mapy.
- Microsoft: analiza CPU, próbki CPU i przełączenia kontekstu.
- Microsoft: xperf cswitch i granice czasu.
- Microsoft: zalecenia dotyczące stałej ochrony Defender.
- Microsoft: liczniki pamięci procesu.
- CapFrameX: karta Variances i porównywanie rozkładów.
- CapFrameX v1.8.6: źródłowe obliczenia Frametime Variance.
- Ogólna metodyka badań Wiki.
Ostatnia weryfikacja: 2026-10-25. Pierwsza wersja z 24 października: cztery etapy na jednym fizycznym komputerze, otwarte pomiary źródłowe i ponowne obliczenia. 25 października dodano delty względem Clean, rozszerzoną tabelę FPS i Frametime Variance. Badanie przygotował deweloper BoosterX. Do niezależnej weryfikacji opublikowano oryginalne zapisy, warunki testu i skrypt do ponownego przeliczenia.