BoosterX : activité en arrière-plan de Windows et FPS dans CS2
Sur cette page
Comparaison de quatre étapes sur un même PC. Après l’application successive des optimisations BoosterX, l’activité en arrière-plan de Windows a diminué et le FPS moyen dans le benchmark CS2 sélectionné a augmenté de 2,23–2,96% par rapport au système Clean préparé. Advanced Advanced a obtenu le FPS moyen le plus élevé, tandis que Expert Hardcore a obtenu le P1 le plus élevé et l’activité la plus faible pendant la période d’inactivité enregistrée.
Les mesures ont été réalisées par le développeur de BoosterX. Le résultat correspond à une seule série sur la configuration indiquée. Les calculs incluent les huit passages FPS et les fenêtres WPR complètes de cinq minutes.
Résultats WPR · Résultats CS2 · Méthodologie · Télécharger les données brutes
Ce qui a été testé
Section intitulée « Ce qui a été testé »Objectif : vérifier l’évolution de l’activité en arrière-plan de Windows et des performances dans un scénario CS2 fixe lors du passage successif de Clean → Safe Advanced → Advanced Advanced → Expert Hardcore.
WPR et CapFrameX répondent à des questions différentes. WPR montre l’activité du système après la connexion et pendant l’inactivité. CapFrameX mesure les intervalles entre les images pendant une charge de jeu. Une réduction de plusieurs fois de l’utilisation du CPU en arrière-plan ne signifie pas, à elle seule, une augmentation équivalente du FPS.
Configuration et préparation
Section intitulée « Configuration et préparation »| Paramètre | Conditions de la série |
|---|---|
| Date des mesures | 24 octobre 2026 |
| CPU | AMD Ryzen 7 7800X3D, 8 cœurs / 16 threads |
| GPU | NVIDIA GeForce RTX 5070, pilote 617.42 |
| RAM | 32 Go, 2 × 16 Go DDR5-6000 |
| Carte mère / BIOS | ASRock B850 Riptide WiFi / 4.20 |
| Windows | Windows 11 Pro 26H2, build 26300.9711 |
| BoosterX | 2.4.2.4, build Debug ; le hachage du fichier binaire utilisé n’a pas été conservé |
| CapFrameX | 1.8.6.2 |
| CS2 | CS2 FPS BENCHMARK DUST2, Workshop ID 3240880604 |
| Graphismes | 1280×960, préréglage Low, FidelityFX désactivé, Reflex activé, fps_max 0 |
| Autres paramètres | ReBAR, Game Mode et HAGS activés ; CapFrameX a identifié le mode de présentation comme Fullscreen Optimized or Borderless |
| Alimentation | Clean, Safe et Advanced : « Équilibré » ; Expert Hardcore : PowerX v2.1 |
Préparation : installation propre de Windows, toutes les mises à jour, Steam, Spotify et pilotes du chipset AMD. Les fichiers CS2 ont été transférés depuis un autre disque. Le pilote vidéo a été supprimé avec DDU, puis réinstallé à l’aide de l’outil d’installation personnalisée avec un ensemble réduit de composants NVIDIA. La liste exacte des composants et la version du pilote du chipset n’ont pas été conservées séparément. Aucune autre modification manuelle n’avait été effectuée avant la mesure de référence.
Ainsi, Clean désigne ici le système préparé avant l’application de BoosterX, déjà équipé des applications et des pilotes. Il ne s’agit pas de Windows immédiatement après le premier écran d’installation. L’ETL Clean contient également l’activité de OneDrive et des composants Edge.
D’après les données des capteurs, la fréquence moyenne du CPU Max pendant les passages FPS était d’environ 5035–5043 MHz, et celle du GPU d’environ 2927–2930 MHz. Les fréquences ont varié : la série n’a pas été réalisée avec des fréquences CPU/GPU fixes. CPU Max ne mesure pas la fréquence effective de chaque cœur. Les paramètres PBO et Curve Optimizer n’ont pas été consignés.
Méthodologie
Section intitulée « Méthodologie »Les quatre états ont été appliqués successivement sur une seule installation de Windows. À chaque étape, un cycle WPR a d’abord été exécuté, puis le test FPS. L’image Clean n’a pas été restaurée entre les étapes ; les modifications se sont accumulées. Une tentative WPR inachevée d’Expert Hardcore, sans ETL, a été conservée dans l’archive. L’enregistrement terminé suivant est inclus dans le récapitulatif. Un passage FPS d’Expert Hardcore a été effectué avant cet enregistrement WPR terminé, et le second après.
WPR : cinq minutes d’enregistrement à partir du lancement de la capture lors de la connexion au système, cinq minutes de stabilisation, puis cinq minutes d’inactivité. Des profils légers d’activité CPU, disque, fichiers et réseau ont été enregistrés. Le calcul a été effectué directement à partir des ETL, entre les marqueurs de début et de fin de chaque phase. La durée de chaque fenêtre diffère de 300 secondes de moins de 0,02 seconde. Les en-têtes des huit ETL indiquent zéro perte d’événements et de tampons.
Le début de la première phase se situait environ à la 15e–23e seconde après le démarrage de Windows. Le temps de démarrage du système d’exploitation n’a pas été mesuré par ce test. Les métriques finales ont été recalculées à partir des ETL.
CS2 : deux passages d’environ 105 secondes par étape. Un scénario automatisé sur la carte a été utilisé. La capture CapFrameX a été lancée manuellement à l’aide d’un raccourci clavier, approximativement au même point de référence. Les débuts n’ont pas été synchronisés image par image. Deux fichiers portant par erreur le nom de processus infinst.exe correspondent également au test CS2. Les noms et le contenu JSON d’origine ont été conservés dans l’archive.
Le build exact de CS2, la version du contenu de la carte au moment de l’enregistrement, la valeur MSAA distincte et la durée de préchauffage préalable n’ont pas été consignés. La version actuelle de la carte Workshop peut différer de celle utilisée. La comparaison porte sur cette carte, et non sur le FPS en match compétitif : les auteurs de la carte signalent séparément la différence entre la simulation locale et le jeu sur serveur.
WPR : activité de Windows en arrière-plan
Section intitulée « WPR : activité de Windows en arrière-plan »| Indicateur | Clean | Safe Advanced | Advanced Advanced | Expert Hardcore |
|---|---|---|---|---|
| Après la connexion : premières 5 minutes d’enregistrement | ||||
| Utilisation moyenne du CPU, % | 1,488Base | 0,411Δ −1,077 p.p.−72,37% | 0,314Δ −1,174 p.p.−78,91% | 0,283Δ −1,205 p.p.−80,99% |
| Pic du CPU sur un intervalle d’environ 1 s, % | 30,60Base | 14,30Δ −16,30 p.p.−53,27% | 11,36Δ −19,24 p.p.−62,89% | 6,44Δ −24,16 p.p.−78,95% |
| Estimation du temps CPU, cœur·s | 71,42Base | 19,73Δ −51,68−72,37% | 15,06Δ −56,35−78,91% | 13,58Δ −57,84−80,98% |
| Changements de contexte / s | 5 781,8Base | 1 330,6Δ −4 451,2−76,99% | 1 006,3Δ −4 775,4−82,59% | 763,3Δ −5 018,5−86,80% |
| Changements de contexte, total | 1 734 523Base | 399 198Δ −1 335 325−76,99% | 301 900Δ −1 432 623−82,59% | 229 000Δ −1 505 523−86,80% |
| Passages des threads à l’état Ready / s | 3 692,2Base | 817,9Δ −2 874,2−77,85% | 614,7Δ −3 077,5−83,35% | 455,7Δ −3 236,5−87,66% |
| Processus à la fin de la fenêtre | 148Base | 96Δ −52−35,14% | 92Δ −56−37,84% | 67Δ −81−54,73% |
| Démarrages de processus pendant la fenêtre | 113Base | 27Δ −86−76,11% | 18Δ −95−84,07% | 16Δ −97−85,84% |
| Threads à la fin de la fenêtre | 2 566Base | 1 718Δ −848−33,05% | 1 643Δ −923−35,97% | 1 349Δ −1 217−47,43% |
| Démarrages de threads pendant la fenêtre | 2 833Base | 1 030Δ −1 803−63,64% | 832Δ −2 001−70,63% | 683Δ −2 150−75,89% |
| Somme des ensembles de travail des processus¹, MiB | 5 054,5Base | 3 283,6Δ −1 770,9−35,04% | 2 954,5Δ −2 099,9−41,55% | 2 234,4Δ −2 820,0−55,79% |
| Somme du commit des processus¹, MiB | 2 589,9Base | 1 685,1Δ −904,8−34,93% | 1 586,2Δ −1 003,7−38,76% | 1 195,6Δ −1 394,3−53,84% |
| Handles des processus¹ | 66 187Base | 43 247Δ −22 940−34,66% | 40 520Δ −25 667−38,78% | 30 987Δ −35 200−53,18% |
| DPC / s | 981,7Base | 347,4Δ −634,3−64,61% | 306,4Δ −675,4−68,79% | 204,2Δ −777,5−79,20% |
| Interruptions matérielles (ISR) / s | 420,1Base | 120,4Δ −299,7−71,34% | 102,7Δ −317,4−75,56% | 92,3Δ −327,8−78,03% |
| Hard faults pendant la fenêtre² | 16 251Base | 9 661Δ −6 590−40,55% | 6 049Δ −10 202−62,78% | 5 271Δ −10 980−67,57% |
| Lecture disque, MiB | 920,36Base | 295,67Δ −624,69−67,87% | 237,00Δ −683,36−74,25% | 218,96Δ −701,40−76,21% |
| Écriture disque, MiB | 758,41Base | 123,43Δ −634,98−83,73% | 89,13Δ −669,28−88,25% | 66,27Δ −692,13−91,26% |
| Dont écritures des fichiers WPR³, MiB | 591,76Base | 85,00Δ −506,76−85,64% | 62,00Δ −529,76−89,52% | 42,00Δ −549,76−92,90% |
| Opérations de lecture disque | 29 124Base | 16 718Δ −12 406−42,60% | 13 234Δ −15 890−54,56% | 12 391Δ −16 733−57,45% |
| Opérations d’écriture disque | 13 298Base | 3 118Δ −10 180−76,55% | 2 157Δ −11 141−83,78% | 1 588Δ −11 710−88,06% |
| Durée de la fenêtre, s | 300,000 | 300,018 | 300,003 | 300,015 |
| Inactivité : dernières 5 minutes du cycle | ||||
| Utilisation moyenne du CPU, % | 1,238Base | 1,694Δ +0,456 p.p.+36,86% | 0,337Δ −0,901 p.p.−72,77% | 0,183Δ −1,055 p.p.−85,25% |
| Pic du CPU sur un intervalle d’environ 1 s, % | 12,17Base | 17,74Δ +5,57 p.p.+45,79% | 6,47Δ −5,70 p.p.−46,86% | 6,25Δ −5,92 p.p.−48,64% |
| Estimation du temps CPU, cœur·s | 59,41Base | 81,31Δ +21,90+36,86% | 16,18Δ −43,23−72,77% | 8,76Δ −50,64−85,25% |
| Changements de contexte / s | 1 944,9Base | 2 061,6Δ +116,7+6,00% | 806,9Δ −1 138,0−58,51% | 336,5Δ −1 608,4−82,70% |
| Changements de contexte, total | 583 440Base | 618 477Δ +35 037+6,01% | 242 071Δ −341 369−58,51% | 100 967Δ −482 473−82,69% |
| Passages des threads à l’état Ready / s | 1 208,0Base | 1 272,0Δ +64,0+5,30% | 522,9Δ −685,1−56,72% | 200,3Δ −1 007,7−83,42% |
| Processus à la fin de la fenêtre | 153Base | 101Δ −52−33,99% | 90Δ −63−41,18% | 64Δ −89−58,17% |
| Démarrages de processus pendant la fenêtre | 19Base | 168Δ +149+784,21% | 6Δ −13−68,42% | 5Δ −14−73,68% |
| Threads à la fin de la fenêtre | 2 388Base | 1 678Δ −710−29,73% | 1 412Δ −976−40,87% | 1 189Δ −1 199−50,21% |
| Démarrages de threads pendant la fenêtre | 1 200Base | 2 321Δ +1 121+93,42% | 541Δ −659−54,92% | 333Δ −867−72,25% |
| Somme des ensembles de travail des processus¹, MiB | 5 150,6Base | 3 477,7Δ −1 672,9−32,48% | 2 890,6Δ −2 260,0−43,88% | 2 202,8Δ −2 947,8−57,23% |
| Somme du commit des processus¹, MiB | 2 847,4Base | 1 796,3Δ −1 051,1−36,91% | 1 587,9Δ −1 259,5−44,23% | 1 223,9Δ −1 623,5−57,02% |
| Handles des processus¹ | 68 628Base | 45 867Δ −22 761−33,17% | 39 888Δ −28 740−41,88% | 30 597Δ −38 031−55,42% |
| DPC / s | 1 210,5Base | 277,5Δ −933,0−77,08% | 216,7Δ −993,7−82,09% | 108,8Δ −1 101,7−91,01% |
| Interruptions matérielles (ISR) / s | 922,1Base | 86,5Δ −835,6−90,62% | 64,3Δ −857,8−93,03% | 46,8Δ −875,3−94,93% |
| Hard faults pendant la fenêtre² | 636Base | 5 258Δ +4 622+726,73% | 1 040Δ +404+63,52% | 1 203Δ +567+89,15% |
| Lecture disque, MiB | 12,90Base | 105,32Δ +92,42+716,28% | 81,50Δ +68,60+531,64% | 9,83Δ −3,07−23,78% |
| Écriture disque, MiB | 214,57Base | 317,84Δ +103,27+48,13% | 86,97Δ −127,60−59,47% | 31,03Δ −183,54−85,54% |
| Dont écritures des fichiers WPR³, MiB | 164,00Base | 172,00Δ +8,00+4,88% | 72,00Δ −92,00−56,10% | 15,00Δ −149,00−90,85% |
| Opérations de lecture disque | 634Base | 5 281Δ +4 647+732,97% | 4 241Δ +3 607+568,93% | 836Δ +202+31,86% |
| Opérations d’écriture disque | 5 690Base | 2 410Δ −3 280−57,64% | 1 250Δ −4 440−78,03% | 1 783Δ −3 907−68,66% |
| Durée de la fenêtre, s | 299,986 | 299,999 | 300,006 | 300,016 |
Sous chaque valeur figure la Δ par rapport à Clean dans la même phase : différence absolue dans les unités de la ligne et variation relative en pourcentage. Pour l’utilisation du CPU, la différence absolue est indiquée en points de pourcentage (p.p.). Un signe moins indique une baisse de la métrique, un signe plus une hausse ; la durée de la fenêtre est indiquée sans delta. Formules : Δ = этап − Clean, Δ% = (этап / Clean − 1) × 100.
Le CPU est calculé à partir des échantillons CPU Usage (Sampled), en tenant compte de la durée des intervalles et en faisant la moyenne sur 16 processeurs logiques. L’estimation du temps CPU est égale à l’utilisation moyenne × la durée de la fenêtre × 16 / 100. Le pic est calculé à partir d’intervalles d’environ une seconde ; les intervalles aux extrémités peuvent être plus courts. Les événements sont comptabilisés dans la fenêtre complète ; les processus et les threads sont ceux présents à la fin de celle-ci, hors Idle. Les lancements comptabilisent les créations répétées d’un même processus.
¹ Mémoire et handles : instantané des compteurs de processus à la fin de l’ETL, après 0,28–0,65 s suivant le marqueur final. Le décalage exact est conservé dans le JSON. La somme des ensembles de travail comptabilise plusieurs fois les pages partagées et n’est pas égale à la quantité de RAM physique utilisée. Le commit des processus indique la mémoire virtuelle allouée qui doit être prise en charge par la RAM ou le fichier d’échange ; il ne correspond pas au volume réellement écrit dans le fichier d’échange. Ces sommes ne décrivent pas l’ensemble de la mémoire du noyau, des pilotes et du cache de fichiers.
² Les hard faults correspondent au chargement depuis le disque d’une page absente de la RAM, y compris les pages de fichiers. Il ne s’agit pas d’erreurs matérielles de mémoire. DPC et ISR indiquent la fréquence des événements, et non la latence d’entrée ou leur durée de traitement.
³ L’écriture WPR est isolée à partir des noms de fichiers des enregistreurs. Elle est déjà incluse dans l’écriture totale sur le disque. Les métriques disque incluent l’activité de l’outil de mesure et ne constituent pas une estimation pure de la charge des applications.
Dans la comparaison entre Clean et Expert Hardcore, l’utilisation du CPU échantillonnée après la connexion a diminué d’environ 5,3 fois, et pendant l’inactivité de 6,8 fois. Les changements de contexte pendant l’inactivité ont diminué d’environ 5,8 fois ; le nombre de processus à la fin de la fenêtre est passé de 153 → 64. Il s’agit de rapports entre des métriques mesurées précises, et non d’un coefficient unique d’« accélération de Windows ».
Pourquoi Safe a été plus chargé pendant l’inactivité
Section intitulée « Pourquoi Safe a été plus chargé pendant l’inactivité »Au cours de la dernière minute d’inactivité de Safe, mscorsvw.exe et ngen.exe étaient en cours d’exécution. mscorsvw.exe a représenté environ 56,4 seconde CPU. CPU moyen par minute : 0,40 → 0,20 → 0,19 → 0,19 → 7,49%. La fenêtre complète s’est donc révélée plus chargée que celle de Clean, bien que les quatre premières minutes aient été plus calmes.
Ce pic est conservé dans le tableau principal. Une seule série séquentielle ne permet pas de distinguer l’effet durable du mode des tâches ponctuelles en arrière-plan et des changements d’état de Windows au fil du temps.
Comment interpréter les métriques de mémoire et de disque
Section intitulée « Comment interpréter les métriques de mémoire et de disque »L’écriture totale sur le disque inclut celle de WPR lui-même. Par exemple, pendant l’inactivité de Clean, sur 214,57 Mio écrits, 164 Mio correspondaient directement aux fichiers des enregistreurs WPR. Cette partie est indiquée sur une ligne distincte du tableau. Le dossier de test se trouvait dans OneDrive ; l’effet de la synchronisation n’a pas été isolé séparément. La vitesse réseau et la consommation électrique ne sont pas comparées dans cette publication.
CS2 : FPS et temps de trame
Section intitulée « CS2 : FPS et temps de trame »| Indicateur | Clean | Safe Advanced | Advanced Advanced | Expert Hardcore |
|---|---|---|---|---|
| FPS moyen | 888,29Base | 911,19Δ +22,91+2,58% | 914,56Δ +26,28+2,96% | 908,08Δ +19,79+2,23% |
| P1 FPS | 296,73Base | 304,42Δ +7,69+2,59% | 308,55Δ +11,82+3,98% | 312,15Δ +15,42+5,20% |
| P0,1 FPS | 259,15Base | 265,90Δ +6,76+2,61% | 260,28Δ +1,13+0,44% | 264,29Δ +5,14+1,98% |
| 1% low : moyenne des images lentes, FPS | 275,50Base | 283,63Δ +8,14+2,95% | 283,41Δ +7,91+2,87% | 288,21Δ +12,71+4,61% |
| Temps d’image moyen, ms | 1,126Base | 1,097Δ −0,028−2,51% | 1,093Δ −0,032−2,87% | 1,101Δ −0,025−2,18% |
| P99 du temps d’image, ms | 3,370Base | 3,285Δ −0,085−2,53% | 3,241Δ −0,129−3,84% | 3,204Δ −0,167−4,95% |
| Écart moyen entre images consécutives, ms | 0,351Base | 0,338Δ −0,013−3,64% | 0,335Δ −0,016−4,53% | 0,329Δ −0,022−6,30% |
| FPS moyen : plage des deux exécutions | 884,85 – 891,72 | 908,79 – 913,59 | 914,55 – 914,57 | 907,57 – 908,59 |
Advanced Advanced a obtenu le FPS moyen le plus élevé : 914,56 contre 888,29 pour Clean, +2,96%. Expert Hardcore a obtenu un FPS moyen légèrement inférieur, mais le P1 le plus élevé : 312,15 contre 296,73, +5,20%. L’étape la plus agressive n’a pas été la meilleure pour toutes les métriques.
Le FPS moyen de chaque passage est égal à 1000 / среднее время кадра в мс. Le P1 est égal à 1000 / P99 времени кадра ; le P99 est calculé par interpolation linéaire sur les images triées. Les résultats d’une étape correspondent à la moyenne des deux résultats. Les deltas absolu et relatif par rapport à Clean sont indiqués sous les valeurs. Pour le FPS, une valeur plus élevée signifie une vitesse supérieure ; pour le temps de trame, une valeur plus faible signifie une vitesse supérieure. La ligne 1% low est calculée séparément comme 1000 / среднее время самых медленных 1% кадров et ne correspond pas au P1.
Les huit passages et les longues images
| Étape / exécution | Images | FPS moyen | P1 FPS | P99, ms | Image la plus longue, 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 |
Tous les intervalles entre les images sont positifs et la séquence temporelle est monotone. Les longues images ont été conservées. Les images ne constituent pas des répétitions indépendantes de l’expérience : il n’y a que deux passages FPS par étape. La plage du tableau indique la variation entre ces deux passages, et non un intervalle de confiance.
L’utilisation moyenne du GPU était d’environ 74–76%, avec des pics allant jusqu’à 95–96%. Ces données ne permettent pas d’affirmer que chaque partie du scénario est exclusivement limitée par le CPU. Le champ PcLatency de CapFrameX n’est pas utilisé comme mesure physique de la latence « mouvement de la souris → lumière à l’écran ».
Frametime Variance : régularité des images
Section intitulée « Frametime Variance : régularité des images »Le principe de l’onglet Variances de CapFrameX a été utilisé : valeur absolue de la différence entre les temps de deux images consécutives |tᵢ − tᵢ₋₁|, en millisecondes. Les paires sont réparties en cinq intervalles : <2, 2–<4, 4–<8, 8–<12 et ≥12 мс. Il s’agit d’une métrique des variations entre images consécutives ; la variance statistique en ms² n’est pas calculée ici. Les limites des intervalles ont été vérifiées dans le code source de CapFrameX v1.8.6.
Avec Expert Hardcore, la proportion de paires présentant une différence à partir de 2 ms est de 4,091% contre 5,879% pour Clean. Cela représente −1,787 p.p., soit −30,4% par rapport à Clean. La baisse est de 18,0% avec Safe Advanced et de 26,1% avec Advanced Advanced. Ces pourcentages correspondent à la proportion de variations entre images consécutives à partir de 2 ms, et non à une augmentation du FPS ou de la précision de visée.
| Écart entre images consécutives | 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. |
Pour chaque étape, les compteurs de paires des deux passages sont regroupés, sans relier la dernière image d’un passage à la première du suivant. Le dénominateur est la somme de N − 1 pour les deux passages. Les proportions sont donc pondérées par le nombre de paires, contrairement à la moyenne des deux valeurs FPS. Les nombres exacts sont conservés dans les fichiers JSON et CSV ; le tableau arrondit les proportions à quatre décimales. CapFrameX les arrondit plus tôt, de sorte que les derniers chiffres affichés peuvent différer.
La baisse principale concerne l’intervalle 2–<4 ms. La proportion de variations de 4–<8 ms est légèrement supérieure avec Expert Hardcore à celle de Clean : 0,0210% contre 0,0166%. Tous les intervalles ont été conservés, y compris les variations rares. Deux passages ne permettent pas d’établir la reproductibilité de cette évolution.
Ce que cela signifie pour la visée : dans ce benchmark, les intervalles entre les images sont devenus plus réguliers au seuil de 2 ms. Un éventuel bénéfice pour la fluidité visuelle du mouvement du réticule reste une hypothèse : l’enregistrement des intervalles entre les images ne mesure ni la précision de visée, ni le mouvement de la souris, ni le délai avant l’apparition de l’image. Cette série ne permet pas de promettre une « visée nettement meilleure ».
Conclusion et limites du résultat
Section intitulée « Conclusion et limites du résultat »Cette série séquentielle a mis en évidence une baisse de l’activité en arrière-plan après la connexion au système. Dans le scénario CS2 sélectionné, les trois étapes suivantes ont toutes obtenu un FPS moyen supérieur à celui du système Clean préparé. Résultat pratique sur cette configuration : environ 2–3% de FPS moyen, Advanced et Expert Hardcore présentant des points forts différents.
Cette étude ne détermine pas la contribution d’un paramètre particulier, l’ampleur universelle du gain, le temps de démarrage de Windows ou la latence physique d’entrée. Expert Hardcore comprend une modification du plan d’alimentation ; c’est donc l’étape dans son ensemble qui est comparée. La réduction du nombre de processus ne constitue pas, à elle seule, une mesure des performances en jeu.
Limites : un PC, ordre fixe des étapes, un seul enregistrement WPR terminé par étape, deux passages FPS, lancement manuel de la capture, build Debug sans hachage du fichier binaire conservé. Les effets de l’ordre, du préchauffage des caches et de la maintenance en arrière-plan ne sont pas dissociés de ceux de l’optimisation. Pendant l’inactivité de Clean, le Gestionnaire des tâches a également été lancé brièvement ; la fenêtre complète a été conservée sans découpage. Cette série ne comporte ni reproduction indépendante ni retour de contrôle à Clean.
Antivirus et FPS
Section intitulée « Antivirus et FPS »Il n’est pas recommandé de désactiver l’antivirus pour gagner des FPS. Cette série compare des ensembles de modifications complets : aucun test ne porte ici sur la seule variable « protection activée / désactivée ». Elle ne prouve donc pas que l’antivirus n’a aucun effet sur le FPS et ne mesure pas séparément le gain de mémoire lié à sa désactivation.
Microsoft recommande de laisser la protection en temps réel activée. En cas de charge notable, il est possible d’utiliser l’analyse des performances de Microsoft Defender pour en trouver la cause précise.
Rétablissement de l’état initial
Section intitulée « Rétablissement de l’état initial »Le rétablissement de l’état initial après Expert Hardcore n’a pas été vérifié dans le cadre de ces mesures. Pour répéter le test avec des états indépendants, il convient de restaurer une image Clean préparée à l’avance et de documenter le retour à cet état. Les limites générales de la restauration sont décrites dans les limites de restauration de BoosterX.
Données brutes et recalcul
Section intitulée « Données brutes et recalcul »8 ETL · 8 CapFrameX JSON · tableaux, graphiques et scripts de recalcul. Pour consulter les résultats, ouvrez README.html dans l’archive. Les enregistrements originaux sont conservés sans modification. Les deux fichiers nommés infinst.exe font également partie du test CS2.
SHA-256 de l’archive7f20104f7eb46428e5e4f383515653b1320827be39fc171d1b5590210d0fbcdd
WPR, CSV · Toutes les exécutions FPS, CSV · Frametime Variance, CSV · Calculs, JSON · Script de recalcul
Une seule archive regroupe les répertoires sources des quatre étapes WPR terminées, la tentative Expert Hardcore inachevée, les huit fichiers JSON CapFrameX d’origine, les scripts d’enregistrement utilisés, la méthodologie, les tableaux, les graphiques et le script de recalcul. Les anciens tests smoke et les archives de service qui les dupliquent ne sont pas inclus. La présence d’un ancien statut de vérification dans les répertoires sources ne modifie pas les calculs présentés ici à partir des ETL.
L’analyse des ETL nécessite Windows Performance Toolkit ; les enregistrements de jeu d’origine peuvent être consultés avec CapFrameX. Le script analysis/analyze.py utilise Python 3 et WPT 10+ ; il ne lance aucun enregistrement et ne modifie pas le système. Les instructions figurent dans README.html. Les sommes de contrôle permettent de vérifier que les fichiers n’ont pas été modifiés ; elles ne prouvent pas que l’expérience s’est déroulée dans les conditions indiquées.
Les traces système sont conservées dans leur format d’origine : elles contiennent des informations techniques sur l’installation de test, notamment les processus, les chemins locaux et les identifiants système. L’archive n’est pas présentée comme anonymisée. Le code source de l’application BoosterX et les fichiers exécutables tiers n’y figurent pas.
Sources et historique
Section intitulée « Sources et historique »- Les enregistrements sources de cette série et le script de recalcul sont disponibles ci-dessus.
- CS2 FPS BENCHMARK DUST2 : description et limites de la carte.
- Microsoft : analyse du CPU, échantillons CPU et changements de contexte.
- Microsoft : xperf cswitch et limites temporelles.
- Microsoft : recommandations concernant la protection permanente de Defender.
- Microsoft : compteurs de mémoire des processus.
- CapFrameX : onglet Variances et comparaison des distributions.
- CapFrameX v1.8.6 : calcul d’origine de Frametime Variance.
- Méthodologie générale des études Wiki.
Dernière vérification : 2026-10-25. Première édition du 24 octobre : quatre étapes sur un seul PC physique, mesures sources ouvertes et recalcul. Le 25 octobre, ajout des deltas par rapport à Clean, du tableau FPS détaillé et de Frametime Variance. Étude préparée par le développeur de BoosterX. Les enregistrements sources, les conditions de test et le script de recalcul sont publiés pour permettre une vérification indépendante.