BoosterX: attività in background di Windows e FPS in CS2
In questa pagina
Confronto di quattro fasi sullo stesso PC. Dopo l’applicazione sequenziale delle ottimizzazioni di BoosterX, l’attività in background di Windows è diminuita e gli FPS medi nel benchmark CS2 selezionato sono aumentati del 2,23–2,96% rispetto al sistema Clean preparato. Advanced Advanced ha ottenuto gli FPS medi più alti, mentre Expert Hardcore ha ottenuto il P1 più alto e l’attività più bassa durante l’inattività registrata.
Le misurazioni sono state effettuate dallo sviluppatore di BoosterX. Il risultato riguarda una singola serie eseguita sulla configurazione indicata. Nei calcoli sono incluse tutte le otto esecuzioni FPS e le finestre WPR complete di cinque minuti.
Risultati WPR · Risultati CS2 · Metodologia · Scarica i dati originali
Cosa è stato verificato
Sezione intitolata “ Cosa è stato verificato”Obiettivo: verificare come cambiano l’attività in background di Windows e le prestazioni in uno scenario CS2 fisso, passando in sequenza da Clean → Safe Advanced → Advanced Advanced → Expert Hardcore.
WPR e CapFrameX rispondono a domande diverse. WPR mostra l’attività del sistema dopo l’accesso e durante l’inattività. CapFrameX misura gli intervalli tra i fotogrammi durante il carico di gioco. Una riduzione di diverse volte della CPU in background non implica di per sé un aumento equivalente degli FPS.
Configurazione e preparazione
Sezione intitolata “ Configurazione e preparazione”| Parametro | Condizioni della serie |
|---|---|
| Data delle misurazioni | 24 ottobre 2026 |
| CPU | AMD Ryzen 7 7800X3D, 8 core / 16 thread |
| GPU | NVIDIA GeForce RTX 5070, driver 617.42 |
| RAM | 32 GB, 2 × 16 GB DDR5-6000 |
| Scheda madre / BIOS | ASRock B850 Riptide WiFi / 4.20 |
| Windows | Windows 11 Pro 26H2, build 26300.9711 |
| BoosterX | 2.4.2.4, build Debug; l’hash del file binario utilizzato non è stato salvato |
| CapFrameX | 1.8.6.2 |
| CS2 | CS2 FPS BENCHMARK DUST2, Workshop ID 3240880604 |
| Grafica | 1280×960, preset Low, FidelityFX disattivato, Reflex attivato, fps_max 0 |
| Altre impostazioni | ReBAR, Game Mode e HAGS attivati; CapFrameX ha rilevato la modalità di presentazione come Fullscreen Optimized or Borderless |
| Alimentazione | Clean, Safe e Advanced: «Bilanciato»; Expert Hardcore: PowerX v2.1 |
Preparazione: installazione pulita di Windows, tutti gli aggiornamenti, Steam, Spotify e driver del chipset AMD. I file di CS2 sono stati trasferiti da un altro disco. Il driver video è stato rimosso con DDU e reinstallato tramite lo strumento di installazione personalizzata, con un set ridotto di componenti NVIDIA. L’elenco esatto dei componenti e la versione del driver del chipset non sono stati salvati separatamente. Prima della misurazione di base non erano state apportate altre modifiche manuali.
Pertanto, qui Clean indica il sistema preparato prima dell’applicazione di BoosterX, già dotato di applicazioni e driver. Non si tratta di Windows subito dopo la prima schermata di installazione. Nell’ETL di Clean è presente anche l’attività di OneDrive e dei componenti di Edge.
Secondo i dati dei sensori, la frequenza media della CPU Max durante le esecuzioni FPS era di circa 5035–5043 MHz, quella della GPU di circa 2927–2930 MHz. Le frequenze variavano: la serie non è stata eseguita con clock CPU/GPU fissi. CPU Max non misura la frequenza effettiva di ciascun core. Le impostazioni di PBO e Curve Optimizer non sono state registrate.
Metodologia
Sezione intitolata “ Metodologia”I quattro stati sono stati applicati in sequenza sulla stessa installazione di Windows. In ogni fase è stato eseguito prima un ciclo WPR, poi il test FPS. Tra una fase e l’altra non è stata ripristinata l’immagine Clean; le modifiche si sono accumulate. Nel pacchetto è conservato un tentativo WPR incompleto di Expert Hardcore, privo di ETL. Nel riepilogo è inclusa la registrazione completata successiva. Una delle esecuzioni FPS di Expert Hardcore è stata effettuata prima di questa registrazione WPR completata, la seconda dopo.
WPR: cinque minuti dopo l’avvio della registrazione all’accesso al sistema, cinque minuti di stabilizzazione, quindi cinque minuti di inattività. Sono stati registrati profili leggeri di attività CPU, disco, file e rete. Il calcolo è stato eseguito direttamente dall’ETL, tra i marcatori di inizio e fine di ciascuna fase. La durata di ogni finestra differisce da 300 secondi di meno di 0,02 secondi. In tutti gli otto ETL, le intestazioni indicano zero eventi e buffer persi.
L’inizio della prima fase cadeva circa al secondo 15–23 dopo l’avvio di Windows. Il tempo di avvio del sistema operativo non è stato misurato con questo test. Le metriche finali sono state ricalcolate dagli ETL.
CS2: due esecuzioni di circa 105 secondi per ogni fase. È stato utilizzato uno scenario automatico della mappa. La registrazione di CapFrameX è stata avviata manualmente con un tasto di scelta rapida, approssimativamente dallo stesso punto di riferimento. Non è stata sincronizzata fotogramma per fotogramma l’inizio delle registrazioni. Anche due file con il nome errato del processo infinst.exe appartengono al test di CS2. Nell’archivio sono conservati i nomi originali e il contenuto JSON.
Non sono stati registrati il build esatto di CS2, la versione dei contenuti della mappa al momento della registrazione, il valore separato di MSAA né la durata del riscaldamento preliminare. La versione attuale della mappa Workshop potrebbe differire da quella utilizzata. Il confronto riguarda questa mappa, non gli FPS in una partita competitiva: gli autori della mappa segnalano separatamente la differenza tra la simulazione locale e il gioco su un server.
WPR: attività di Windows in background
Sezione intitolata “ WPR: attività di Windows in background”| Metrica | Clean | Safe Advanced | Advanced Advanced | Expert Hardcore |
|---|---|---|---|---|
| Dopo l’accesso: registrazione dei primi 5 minuti | ||||
| Utilizzo medio della CPU, % | 1,488Baseline | 0,411Δ −1,077 p.p.−72,37% | 0,314Δ −1,174 p.p.−78,91% | 0,283Δ −1,205 p.p.−80,99% |
| Picco CPU nell’intervallo di circa 1 s, % | 30,60Baseline | 14,30Δ −16,30 p.p.−53,27% | 11,36Δ −19,24 p.p.−62,89% | 6,44Δ −24,16 p.p.−78,95% |
| Stima del tempo CPU, core·s | 71,42Baseline | 19,73Δ −51,68−72,37% | 15,06Δ −56,35−78,91% | 13,58Δ −57,84−80,98% |
| Cambi di contesto / s | 5781,8Baseline | 1330,6Δ −4451,2−76,99% | 1006,3Δ −4775,4−82,59% | 763,3Δ −5018,5−86,80% |
| Cambi di contesto totali | 1.734.523Baseline | 399.198Δ −1.335.325−76,99% | 301.900Δ −1.432.623−82,59% | 229.000Δ −1.505.523−86,80% |
| Transizioni dei thread allo stato Ready / s | 3692,2Baseline | 817,9Δ −2874,2−77,85% | 614,7Δ −3077,5−83,35% | 455,7Δ −3236,5−87,66% |
| Processi alla fine della finestra | 148Baseline | 96Δ −52−35,14% | 92Δ −56−37,84% | 67Δ −81−54,73% |
| Avvii di processi durante la finestra | 113Baseline | 27Δ −86−76,11% | 18Δ −95−84,07% | 16Δ −97−85,84% |
| Thread alla fine della finestra | 2566Baseline | 1718Δ −848−33,05% | 1643Δ −923−35,97% | 1349Δ −1217−47,43% |
| Avvii di thread durante la finestra | 2833Baseline | 1030Δ −1803−63,64% | 832Δ −2001−70,63% | 683Δ −2150−75,89% |
| Somma dei working set dei processi¹, MiB | 5054,5Baseline | 3283,6Δ −1770,9−35,04% | 2954,5Δ −2099,9−41,55% | 2234,4Δ −2820,0−55,79% |
| Somma del commit dei processi¹, MiB | 2589,9Baseline | 1685,1Δ −904,8−34,93% | 1586,2Δ −1003,7−38,76% | 1195,6Δ −1394,3−53,84% |
| Handle dei processi¹ | 66.187Baseline | 43.247Δ −22.940−34,66% | 40.520Δ −25.667−38,78% | 30.987Δ −35.200−53,18% |
| DPC / s | 981,7Baseline | 347,4Δ −634,3−64,61% | 306,4Δ −675,4−68,79% | 204,2Δ −777,5−79,20% |
| Interrupt hardware (ISR) / s | 420,1Baseline | 120,4Δ −299,7−71,34% | 102,7Δ −317,4−75,56% | 92,3Δ −327,8−78,03% |
| Hard fault durante la finestra² | 16.251Baseline | 9661Δ −6590−40,55% | 6049Δ −10.202−62,78% | 5271Δ −10.980−67,57% |
| Lettura dal disco, MiB | 920,36Baseline | 295,67Δ −624,69−67,87% | 237,00Δ −683,36−74,25% | 218,96Δ −701,40−76,21% |
| Scrittura sul disco, MiB | 758,41Baseline | 123,43Δ −634,98−83,73% | 89,13Δ −669,28−88,25% | 66,27Δ −692,13−91,26% |
| Di cui scrittura dei file WPR³, MiB | 591,76Baseline | 85,00Δ −506,76−85,64% | 62,00Δ −529,76−89,52% | 42,00Δ −549,76−92,90% |
| Operazioni di lettura dal disco | 29.124Baseline | 16.718Δ −12.406−42,60% | 13.234Δ −15.890−54,56% | 12.391Δ −16.733−57,45% |
| Operazioni di scrittura sul disco | 13.298Baseline | 3118Δ −10.180−76,55% | 2157Δ −11.141−83,78% | 1588Δ −11.710−88,06% |
| Durata della finestra, s | 300,000 | 300,018 | 300,003 | 300,015 |
| Inattività: ultimi 5 minuti del ciclo | ||||
| Utilizzo medio della CPU, % | 1,238Baseline | 1,694Δ +0,456 p.p.+36,86% | 0,337Δ −0,901 p.p.−72,77% | 0,183Δ −1,055 p.p.−85,25% |
| Picco CPU nell’intervallo di circa 1 s, % | 12,17Baseline | 17,74Δ +5,57 p.p.+45,79% | 6,47Δ −5,70 p.p.−46,86% | 6,25Δ −5,92 p.p.−48,64% |
| Stima del tempo CPU, core·s | 59,41Baseline | 81,31Δ +21,90+36,86% | 16,18Δ −43,23−72,77% | 8,76Δ −50,64−85,25% |
| Cambi di contesto / s | 1944,9Baseline | 2061,6Δ +116,7+6,00% | 806,9Δ −1138,0−58,51% | 336,5Δ −1608,4−82,70% |
| Cambi di contesto totali | 583.440Baseline | 618.477Δ +35.037+6,01% | 242.071Δ −341.369−58,51% | 100.967Δ −482.473−82,69% |
| Transizioni dei thread allo stato Ready / s | 1208,0Baseline | 1272,0Δ +64,0+5,30% | 522,9Δ −685,1−56,72% | 200,3Δ −1007,7−83,42% |
| Processi alla fine della finestra | 153Baseline | 101Δ −52−33,99% | 90Δ −63−41,18% | 64Δ −89−58,17% |
| Avvii di processi durante la finestra | 19Baseline | 168Δ +149+784,21% | 6Δ −13−68,42% | 5Δ −14−73,68% |
| Thread alla fine della finestra | 2388Baseline | 1678Δ −710−29,73% | 1412Δ −976−40,87% | 1189Δ −1199−50,21% |
| Avvii di thread durante la finestra | 1200Baseline | 2321Δ +1121+93,42% | 541Δ −659−54,92% | 333Δ −867−72,25% |
| Somma dei working set dei processi¹, MiB | 5150,6Baseline | 3477,7Δ −1672,9−32,48% | 2890,6Δ −2260,0−43,88% | 2202,8Δ −2947,8−57,23% |
| Somma del commit dei processi¹, MiB | 2847,4Baseline | 1796,3Δ −1051,1−36,91% | 1587,9Δ −1259,5−44,23% | 1223,9Δ −1623,5−57,02% |
| Handle dei processi¹ | 68.628Baseline | 45.867Δ −22.761−33,17% | 39.888Δ −28.740−41,88% | 30.597Δ −38.031−55,42% |
| DPC / s | 1210,5Baseline | 277,5Δ −933,0−77,08% | 216,7Δ −993,7−82,09% | 108,8Δ −1101,7−91,01% |
| Interrupt hardware (ISR) / s | 922,1Baseline | 86,5Δ −835,6−90,62% | 64,3Δ −857,8−93,03% | 46,8Δ −875,3−94,93% |
| Hard fault durante la finestra² | 636Baseline | 5258Δ +4622+726,73% | 1040Δ +404+63,52% | 1203Δ +567+89,15% |
| Lettura dal disco, MiB | 12,90Baseline | 105,32Δ +92,42+716,28% | 81,50Δ +68,60+531,64% | 9,83Δ −3,07−23,78% |
| Scrittura sul disco, MiB | 214,57Baseline | 317,84Δ +103,27+48,13% | 86,97Δ −127,60−59,47% | 31,03Δ −183,54−85,54% |
| Di cui scrittura dei file WPR³, MiB | 164,00Baseline | 172,00Δ +8,00+4,88% | 72,00Δ −92,00−56,10% | 15,00Δ −149,00−90,85% |
| Operazioni di lettura dal disco | 634Baseline | 5281Δ +4647+732,97% | 4241Δ +3607+568,93% | 836Δ +202+31,86% |
| Operazioni di scrittura sul disco | 5690Baseline | 2410Δ −3280−57,64% | 1250Δ −4440−78,03% | 1783Δ −3907−68,66% |
| Durata della finestra, s | 299,986 | 299,999 | 300,006 | 300,016 |
Sotto ogni valore è mostrata la Δ rispetto a Clean nella stessa fase: differenza assoluta nelle unità della riga e variazione relativa in percentuale. Per il carico CPU, la differenza assoluta è indicata in punti percentuali (p.p.). Il segno meno indica una diminuzione dell’indicatore, il segno più un aumento; la durata della finestra è riportata senza delta. Formule: Δ = этап − Clean, Δ% = (этап / Clean − 1) × 100.
La CPU è calcolata in base ai campioni CPU Usage (Sampled), tenendo conto della durata degli intervalli e facendo la media su 16 processori logici. La stima del tempo CPU è pari al carico medio × durata della finestra × 16 / 100. Il picco è ricavato da intervalli di circa un secondo; gli intervalli ai margini possono essere più brevi. Gli eventi sono conteggiati all’interno della finestra completa; processi e thread sono riferiti alla sua fine, escluso Idle. Gli avvii tengono conto della ricreazione dello stesso processo.
¹ Memoria e handle: snapshot dei contatori dei processi al completamento dell’ETL, dopo 0,28–0,65 s dal marcatore finale. Lo scarto esatto è salvato nel JSON. La somma dei working set conteggia nuovamente le pagine condivise e non equivale alla RAM fisica occupata. Il commit dei processi indica la memoria virtuale allocata che deve essere supportata dalla RAM o dal file di paging; non è la quantità di dati effettivamente scritta nel file di paging. Queste somme non descrivono tutta la memoria del kernel, dei driver e della cache dei file.
² Gli hard fault indicano il caricamento dal disco di una pagina assente dalla RAM, comprese le pagine dei file. Non sono errori hardware della memoria. DPC e ISR indicano la frequenza degli eventi, non la latenza di input né la durata della loro elaborazione.
³ La scrittura WPR è stata isolata in base ai nomi dei file dei logger. È già inclusa nella scrittura totale su disco. Le metriche del disco includono l’attività dello strumento di misurazione e non costituiscono una stima pura del carico delle applicazioni.
Nel confronto tra Clean ed Expert Hardcore, il carico CPU campionato dopo l’accesso è diminuito di circa 5,3 volte, durante l’inattività di 6,8 volte. I cambi di contesto durante l’inattività sono diminuiti di circa 5,8 volte; numero di processi alla fine della finestra: 153 → 64. Si tratta di rapporti tra metriche misurate specifiche, non di un unico coefficiente di «accelerazione di Windows».
Perché Safe è risultato più pesante durante l’inattività
Sezione intitolata “ Perché Safe è risultato più pesante durante l’inattività”Nell’ultimo minuto di inattività di Safe erano in esecuzione mscorsvw.exe e ngen.exe. A mscorsvw.exe sono stati attribuiti circa 56,4 secondi di CPU. CPU medio per minuto: 0,40 → 0,20 → 0,19 → 0,19 → 7,49%. Di conseguenza, la finestra completa è risultata più pesante di Clean, anche se i primi quattro minuti erano più tranquilli.
Questo picco è mantenuto nella tabella principale. Da una sola serie sequenziale non è possibile distinguere l’effetto stabile della modalità dalle attività in background occasionali e dai cambiamenti dello stato di Windows nel tempo.
Come leggere gli indicatori di memoria e disco
Sezione intitolata “ Come leggere gli indicatori di memoria e disco”La scrittura totale su disco include quella dello stesso WPR. Per esempio, durante l’inattività di Clean, dei 214,57 MiB scritti, 164 MiB sono stati scritti direttamente nei file dei logger WPR. Questa parte è indicata separatamente nella tabella. La cartella del test si trovava in OneDrive; l’effetto della sincronizzazione non è stato isolato separatamente. In questa pubblicazione non vengono confrontati la velocità di rete e il consumo energetico.
CS2: FPS e frame time
Sezione intitolata “ CS2: FPS e frame time”| Metrica | Clean | Safe Advanced | Advanced Advanced | Expert Hardcore |
|---|---|---|---|---|
| FPS medio | 888,29Baseline | 911,19Δ +22,91+2,58% | 914,56Δ +26,28+2,96% | 908,08Δ +19,79+2,23% |
| P1 FPS | 296,73Baseline | 304,42Δ +7,69+2,59% | 308,55Δ +11,82+3,98% | 312,15Δ +15,42+5,20% |
| P0,1 FPS | 259,15Baseline | 265,90Δ +6,76+2,61% | 260,28Δ +1,13+0,44% | 264,29Δ +5,14+1,98% |
| 1% low: media dei frame lenti, FPS | 275,50Baseline | 283,63Δ +8,14+2,95% | 283,41Δ +7,91+2,87% | 288,21Δ +12,71+4,61% |
| Tempo medio dei frame, ms | 1,126Baseline | 1,097Δ −0,028−2,51% | 1,093Δ −0,032−2,87% | 1,101Δ −0,025−2,18% |
| P99 del tempo dei frame, ms | 3,370Baseline | 3,285Δ −0,085−2,53% | 3,241Δ −0,129−3,84% | 3,204Δ −0,167−4,95% |
| Differenza media tra frame consecutivi, ms | 0,351Baseline | 0,338Δ −0,013−3,64% | 0,335Δ −0,016−4,53% | 0,329Δ −0,022−6,30% |
| FPS medio: intervallo delle due esecuzioni | 884,85 – 891,72 | 908,79 – 913,59 | 914,55 – 914,57 | 907,57 – 908,59 |
Advanced Advanced ha ottenuto gli FPS medi più alti: 914,56 contro 888,29 di Clean, +2,96%. Expert Hardcore ha ottenuto FPS medi leggermente inferiori, ma il P1 più alto: 312,15 contro 296,73, +5,20%. La fase più aggressiva non è risultata la migliore per tutte le metriche.
Gli FPS medi di ogni esecuzione sono pari a 1000 / среднее время кадра в мс. Il P1 è pari a 1000 / P99 времени кадра; il P99 è calcolato mediante interpolazione lineare sui fotogrammi ordinati. I risultati della fase sono le medie dei due risultati. Sotto i valori sono mostrate le delta assolute e relative rispetto a Clean. Per gli FPS, un valore maggiore indica una maggiore velocità; per il frame time, un valore minore indica una maggiore velocità. La riga 1% low è calcolata separatamente come 1000 / среднее время самых медленных 1% кадров e non coincide con il P1.
Tutte le otto esecuzioni e i fotogrammi lunghi
| Fase / esecuzione | Frame | FPS medio | P1 FPS | P99, ms | Frame più lungo, 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 |
Tutti gli intervalli tra i fotogrammi sono positivi e la sequenza temporale è monotona. I fotogrammi lunghi sono mantenuti. I fotogrammi non sono repliche indipendenti dell’esperimento: ci sono solo due esecuzioni FPS per fase. L’intervallo nella tabella mostra la variabilità tra queste due esecuzioni, non un intervallo di confidenza.
Il carico medio della GPU era di circa 74–76%, con picchi fino a 95–96%. Questi dati non consentono di dichiarare che ogni parte dello scenario sia limitata esclusivamente dalla CPU. Il campo PcLatency di CapFrameX non viene utilizzato come misura della latenza fisica «movimento del mouse → luce sullo schermo».
Frametime Variance: uniformità dei fotogrammi
Sezione intitolata “ Frametime Variance: uniformità dei fotogrammi”È stato utilizzato il principio della scheda Variances di CapFrameX: valore assoluto della differenza tra i tempi di due fotogrammi consecutivi |tᵢ − tᵢ₋₁|, in millisecondi. Le coppie sono distribuite in cinque intervalli: <2, 2–<4, 4–<8, 8–<12 e ≥12 мс. È un indicatore delle variazioni tra fotogrammi consecutivi; qui non viene calcolata la varianza statistica in ms². I limiti degli intervalli sono stati verificati con il codice sorgente di CapFrameX v1.8.6.
In Expert Hardcore, la quota di coppie con una differenza da 2 ms è pari a 4,091% contro 5,879% di Clean. Si tratta di −1,787 p.p., ovvero −30,4% rispetto a Clean. In Safe Advanced la riduzione è pari a 18,0%, in Advanced Advanced a 26,1%. Queste percentuali si riferiscono alla quota di variazioni tra fotogrammi consecutivi da 2 ms, non all’aumento degli FPS o alla precisione della mira.
| Differenza tra frame consecutivi | 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. |
Per ogni fase sono stati aggregati i conteggi delle coppie delle due esecuzioni, senza collegare l’ultimo fotogramma di un’esecuzione al primo dell’altra. Il denominatore è la somma di N − 1 per le due esecuzioni. Le quote sono quindi ponderate in base al numero di coppie, a differenza della media dei due valori FPS. Nel JSON e nel CSV sono conservati i conteggi esatti; la tabella arrotonda le quote a quattro cifre decimali. CapFrameX le arrotonda prima, quindi le ultime cifre visualizzate possono differire.
La riduzione principale riguarda l’intervallo 2–<4 ms. La quota di variazioni 4–<8 ms in Expert Hardcore è leggermente superiore a quella di Clean: 0,0210% contro 0,0166%. Sono mantenuti tutti gli intervalli, comprese le variazioni rare. Con due esecuzioni non è possibile stabilire se questa variazione sia riproducibile.
Cosa significa per la mira: in questo benchmark, gli intervalli tra i fotogrammi sono diventati più uniformi rispetto alla soglia di 2 ms. Un possibile beneficio per la fluidità visiva del movimento del mirino resta un’ipotesi: la registrazione degli intervalli tra i fotogrammi non misura la precisione della mira, il movimento del mouse o la latenza fino alla comparsa dell’immagine. Sulla base di questa serie non è possibile promettere una «mira molto migliore».
Conclusioni e limiti del risultato
Sezione intitolata “ Conclusioni e limiti del risultato”In questa serie sequenziale è stata registrata una riduzione dell’attività in background dopo l’accesso al sistema. Nello scenario CS2 selezionato, tutte e tre le fasi successive hanno ottenuto FPS medi superiori a quelli del sistema Clean preparato. Risultato pratico su questa configurazione: circa 2–3% di FPS medi, con punti di forza diversi per Advanced ed Expert Hardcore.
Lo studio non determina il contributo di una singola impostazione, l’entità universale dell’aumento, il tempo di avvio di Windows o la latenza fisica di input. Expert Hardcore include una modifica del piano di alimentazione, quindi viene confrontata l’intera fase. La riduzione del numero di processi non è di per sé una misura delle prestazioni di gioco.
Limiti: un PC, ordine delle fasi fisso, un caricamento WPR completato per fase, due esecuzioni FPS, avvio manuale dell’acquisizione, build Debug senza hash del file binario salvato. Gli effetti dell’ordine, del riscaldamento delle cache e della manutenzione in background non sono stati separati da quelli dell’ottimizzazione. Durante l’inattività di Clean è stato avviato brevemente anche Task Manager; la finestra completa è stata mantenuta senza rimuovere alcuna parte. In questa serie non sono stati effettuati né una riproduzione indipendente né un ripristino di controllo a Clean.
Antivirus e FPS
Sezione intitolata “ Antivirus e FPS”Non è consigliabile disattivare l’antivirus per aumentare gli FPS. Questa serie confronta insiemi di modifiche nel loro complesso: non è stato eseguito un test con la sola variabile «protezione attivata / disattivata». Pertanto, non dimostra che l’antivirus non abbia alcun effetto sugli FPS e non misura separatamente il risparmio di memoria derivante dalla sua disattivazione.
Microsoft consiglia di mantenere attiva la protezione in tempo reale. In caso di carico significativo, è disponibile l’analisi delle prestazioni di Microsoft Defender, che consente di individuare la causa specifica.
Ripristino dello stato
Sezione intitolata “ Ripristino dello stato”Il ripristino dello stato originale dopo Expert Hardcore non è stato verificato nell’ambito di queste misurazioni. Per ripetere il test con stati indipendenti, è necessario ripristinare un’immagine Clean preparata in anticipo e documentare il ripristino. I limiti generali del rollback sono descritti nei limiti del ripristino di BoosterX.
Dati originali e ricalcolo
Sezione intitolata “ Dati originali e ricalcolo”8 ETL · 8 JSON CapFrameX · tabelle, grafici e script di ricalcolo. Per visualizzare i risultati, apri README.html all’interno dell’archivio. Le registrazioni originali sono state conservate senza modifiche. Anche i due file chiamati infinst.exe fanno parte del test CS2.
SHA-256 dell’archivio7f20104f7eb46428e5e4f383515653b1320827be39fc171d1b5590210d0fbcdd
WPR, CSV · Tutte le esecuzioni FPS, CSV · Frametime Variance, CSV · Calcoli, JSON · Script di ricalcolo
In un unico archivio sono raccolti i cataloghi originali delle quattro fasi WPR completate, il tentativo incompleto di Expert Hardcore, gli otto file JSON originali di CapFrameX, gli script di registrazione utilizzati, la metodologia, le tabelle, i grafici e il codice sorgente del ricalcolo. I vecchi smoke test e gli archivi di servizio che li duplicano non sono inclusi. La presenza di un vecchio stato di verifica nei cataloghi originali non modifica i calcoli qui riportati, ricavati dagli ETL.
Per analizzare autonomamente gli ETL è necessario Windows Performance Toolkit; per le registrazioni di gioco originali è possibile utilizzare CapFrameX. Lo script analysis/analyze.py utilizza Python 3 e WPT 10+, non avvia registrazioni e non modifica il sistema. Le istruzioni sono disponibili in README.html. I checksum consentono di verificare che i file non siano stati modificati; non dimostrano che le condizioni dell’esperimento siano state rispettate.
Le tracce di sistema sono conservate nel formato originale: contengono informazioni tecniche sull’installazione di test, inclusi processi, percorsi locali e identificatori di sistema. L’archivio non è dichiarato anonimizzato. Non include il codice sorgente dell’applicazione BoosterX né file eseguibili di terze parti.
Fonti e cronologia
Sezione intitolata “ Fonti e cronologia”- Le registrazioni originali di questa serie e lo script di ricalcolo sono disponibili sopra.
- CS2 FPS BENCHMARK DUST2: descrizione e limiti della mappa.
- Microsoft: CPU Analysis, campioni CPU e cambi di contesto.
- Microsoft: xperf cswitch e limiti temporali.
- Microsoft: raccomandazioni per mantenere attiva la protezione Defender.
- Microsoft: contatori della memoria dei processi.
- CapFrameX: scheda Variances e confronto delle distribuzioni.
- CapFrameX v1.8.6: calcolo originale di Frametime Variance.
- Metodologia generale delle ricerche Wiki.
Ultima verifica: 2026-10-25. Prima edizione del 24 ottobre: quattro fasi su un unico PC fisico, misurazioni originali aperte e ricalcolo. Il 25 ottobre sono state aggiunte le delta rispetto a Clean, la tabella FPS ampliata e Frametime Variance. Lo studio è stato preparato dallo sviluppatore di BoosterX. Per una verifica indipendente sono pubblicati le registrazioni originali, le condizioni del test e lo script di ricalcolo.