BoosterX: atividade em segundo plano do Windows e FPS no CS2
Nesta página
Comparação de quatro etapas no mesmo PC. Após a aplicação sequencial das otimizações do BoosterX, a atividade em segundo plano do Windows diminuiu e o FPS médio no benchmark CS2 selecionado aumentou 2,23–2,96% em relação ao sistema Clean preparado. Advanced Advanced obteve o FPS médio mais elevado; Expert Hardcore obteve o P1 mais elevado e a menor atividade durante o período de inatividade registado.
As medições foram realizadas pelo programador do BoosterX. O resultado diz respeito a uma única série no sistema indicado. Os cálculos incluem as oito execuções de FPS e as janelas WPR completas de cinco minutos.
Resultados WPR · Resultados CS2 · Metodologia · Transferir dados de origem
O que foi testado
Seção intitulada “ O que foi testado”Objetivo: verificar como variam a atividade em segundo plano do Windows e o desempenho num cenário fixo de CS2 durante a transição sequencial Clean → Safe Advanced → Advanced Advanced → Expert Hardcore.
WPR e CapFrameX respondem a perguntas diferentes. O WPR mostra a atividade do sistema após o início de sessão e durante o período de inatividade. O CapFrameX mede os intervalos entre fotogramas durante a carga de jogo. Uma redução de várias vezes na utilização de CPU em segundo plano não significa, por si só, um aumento equivalente do FPS.
Sistema de teste e preparação
Seção intitulada “ Sistema de teste e preparação”| Parâmetro | Condições da série |
|---|---|
| Data das medições | 24 de outubro de 2026 |
| CPU | AMD Ryzen 7 7800X3D, 8 núcleos / 16 threads |
| GPU | NVIDIA GeForce RTX 5070, controlador 617.42 |
| RAM | 32 GB, 2 × 16 GB DDR5-6000 |
| Placa / BIOS | ASRock B850 Riptide WiFi / 4.20 |
| Windows | Windows 11 Pro 26H2, compilação 26300.9711 |
| BoosterX | 2.4.2.4, compilação Debug; o hash do ficheiro binário utilizado não foi guardado |
| CapFrameX | 1.8.6.2 |
| CS2 | CS2 FPS BENCHMARK DUST2, Workshop ID 3240880604 |
| Gráficos | 1280×960, predefinição Low, FidelityFX desativado, Reflex ativado, fps_max 0 |
| Outras definições | ReBAR, Game Mode e HAGS ativados; o CapFrameX identificou o modo de apresentação como Fullscreen Optimized or Borderless |
| Energia | Clean, Safe e Advanced: «Equilibrado»; Expert Hardcore: PowerX v2.1 |
Preparação: instalação limpa do Windows, todas as atualizações, Steam, Spotify e controladores do chipset AMD. Os ficheiros de CS2 foram transferidos de outro disco. O controlador de vídeo foi removido com o DDU e reinstalado através da ferramenta de instalação personalizada, com um conjunto reduzido de componentes NVIDIA. A composição exata dos componentes e a versão do controlador do chipset não foram guardadas separadamente. Não foram feitas outras alterações manuais antes da medição de base.
Assim, Clean significa aqui o sistema preparado antes da aplicação do BoosterX, já com aplicações e controladores. Não corresponde ao Windows imediatamente após o primeiro ecrã de instalação. O ETL de Clean também inclui atividade do OneDrive e de componentes do Edge.
De acordo com os dados dos sensores, a frequência média de CPU Max durante as execuções de FPS foi de cerca de 5035–5043 MHz, e a da GPU, de cerca de 2927–2930 MHz. As frequências variaram: a série não foi realizada com clocks de CPU/GPU fixos. CPU Max não é uma medição da frequência efetiva de cada núcleo. As definições de PBO e Curve Optimizer não foram registadas.
Metodologia
Seção intitulada “ Metodologia”Os quatro estados foram aplicados sequencialmente na mesma instalação do Windows. Em cada etapa, foi primeiro executado um ciclo WPR e, em seguida, o teste de FPS. Não houve reposição da imagem Clean entre etapas; as alterações foram-se acumulando. O conjunto inclui uma tentativa WPR incompleta de Expert Hardcore, sem ETL. Foi incluída no resumo a gravação concluída seguinte. Uma execução de FPS de Expert Hardcore foi realizada antes dessa gravação WPR concluída e a segunda, depois.
WPR: cinco minutos após o início da gravação no início de sessão, cinco minutos de estabilização e, em seguida, cinco minutos de inatividade. Foram gravados perfis ligeiros de atividade de CPU, disco, ficheiros e rede. O cálculo foi feito diretamente a partir do ETL, entre os marcadores de início e fim de cada fase. A duração de cada janela difere de 300 segundos em menos de 0,02 segundos. Nos oito ETL, os cabeçalhos indicam zero eventos e buffers perdidos.
O início da primeira fase ocorreu aproximadamente entre o segundo 15 e o 23 após o arranque do Windows. O tempo de arranque do SO não foi medido por este teste. As métricas finais foram recalculadas a partir do ETL.
CS2: duas execuções de aproximadamente 105 segundos por etapa. Foi utilizado um cenário automatizado do mapa. A gravação do CapFrameX foi iniciada manualmente com uma tecla de atalho, aproximadamente no mesmo ponto de referência. O início não foi sincronizado fotograma a fotograma. Os dois ficheiros com o nome de processo incorreto infinst.exe também dizem respeito ao teste de CS2. Os nomes e conteúdos JSON originais foram preservados no arquivo.
A compilação exata de CS2, a versão do conteúdo do mapa no momento da gravação, o valor separado de MSAA e a duração do aquecimento prévio não foram registados. A versão atual do mapa no Workshop pode diferir da utilizada. A comparação diz respeito a este mapa, não ao FPS num jogo competitivo: os autores do mapa assinalam separadamente a diferença entre a simulação local e o jogo num servidor.
WPR: atividade do Windows em segundo plano
Seção intitulada “ WPR: atividade do Windows em segundo plano”| Indicador | Clean | Safe Advanced | Advanced Advanced | Expert Hardcore |
|---|---|---|---|---|
| Após iniciar sessão: primeiros 5 minutos de gravação | ||||
| Utilização média do 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% |
| Pico do CPU num intervalo de cerca de 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% |
| Estimativa do tempo de CPU, núcleo·s | 71,42Base | 19,73Δ −51,68−72,37% | 15,06Δ −56,35−78,91% | 13,58Δ −57,84−80,98% |
| Mudanças de contexto / s | 5781,8Base | 1330,6Δ −4451,2−76,99% | 1006,3Δ −4775,4−82,59% | 763,3Δ −5018,5−86,80% |
| Mudanças de contexto, 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% |
| Transições de threads para Ready / s | 3692,2Base | 817,9Δ −2874,2−77,85% | 614,7Δ −3077,5−83,35% | 455,7Δ −3236,5−87,66% |
| Processos no fim do intervalo | 148Base | 96Δ −52−35,14% | 92Δ −56−37,84% | 67Δ −81−54,73% |
| Processos iniciados durante o intervalo | 113Base | 27Δ −86−76,11% | 18Δ −95−84,07% | 16Δ −97−85,84% |
| Threads no fim do intervalo | 2566Base | 1718Δ −848−33,05% | 1643Δ −923−35,97% | 1349Δ −1217−47,43% |
| Threads iniciadas durante o intervalo | 2833Base | 1030Δ −1803−63,64% | 832Δ −2001−70,63% | 683Δ −2150−75,89% |
| Soma dos conjuntos de trabalho dos processos¹, MiB | 5054,5Base | 3283,6Δ −1770,9−35,04% | 2954,5Δ −2099,9−41,55% | 2234,4Δ −2820,0−55,79% |
| Soma do commit dos processos¹, MiB | 2589,9Base | 1685,1Δ −904,8−34,93% | 1586,2Δ −1003,7−38,76% | 1195,6Δ −1394,3−53,84% |
| Descritores dos processos¹ | 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% |
| Interrupções de hardware (ISR) / s | 420,1Base | 120,4Δ −299,7−71,34% | 102,7Δ −317,4−75,56% | 92,3Δ −327,8−78,03% |
| Hard faults durante o intervalo² | 16 251Base | 9661Δ −6590−40,55% | 6049Δ −10 202−62,78% | 5271Δ −10 980−67,57% |
| Leitura do disco, MiB | 920,36Base | 295,67Δ −624,69−67,87% | 237,00Δ −683,36−74,25% | 218,96Δ −701,40−76,21% |
| Escrita no disco, MiB | 758,41Base | 123,43Δ −634,98−83,73% | 89,13Δ −669,28−88,25% | 66,27Δ −692,13−91,26% |
| Inclui escrita de ficheiros WPR³, MiB | 591,76Base | 85,00Δ −506,76−85,64% | 62,00Δ −529,76−89,52% | 42,00Δ −549,76−92,90% |
| Operações de leitura do disco | 29 124Base | 16 718Δ −12 406−42,60% | 13 234Δ −15 890−54,56% | 12 391Δ −16 733−57,45% |
| Operações de escrita no disco | 13 298Base | 3118Δ −10 180−76,55% | 2157Δ −11 141−83,78% | 1588Δ −11 710−88,06% |
| Duração do intervalo, s | 300,000 | 300,018 | 300,003 | 300,015 |
| Inatividade: últimos 5 minutos do ciclo | ||||
| Utilização média do 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% |
| Pico do CPU num intervalo de cerca de 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% |
| Estimativa do tempo de CPU, núcleo·s | 59,41Base | 81,31Δ +21,90+36,86% | 16,18Δ −43,23−72,77% | 8,76Δ −50,64−85,25% |
| Mudanças de contexto / s | 1944,9Base | 2061,6Δ +116,7+6,00% | 806,9Δ −1138,0−58,51% | 336,5Δ −1608,4−82,70% |
| Mudanças de contexto, total | 583 440Base | 618 477Δ +35 037+6,01% | 242 071Δ −341 369−58,51% | 100 967Δ −482 473−82,69% |
| Transições de threads para Ready / s | 1208,0Base | 1272,0Δ +64,0+5,30% | 522,9Δ −685,1−56,72% | 200,3Δ −1007,7−83,42% |
| Processos no fim do intervalo | 153Base | 101Δ −52−33,99% | 90Δ −63−41,18% | 64Δ −89−58,17% |
| Processos iniciados durante o intervalo | 19Base | 168Δ +149+784,21% | 6Δ −13−68,42% | 5Δ −14−73,68% |
| Threads no fim do intervalo | 2388Base | 1678Δ −710−29,73% | 1412Δ −976−40,87% | 1189Δ −1199−50,21% |
| Threads iniciadas durante o intervalo | 1200Base | 2321Δ +1121+93,42% | 541Δ −659−54,92% | 333Δ −867−72,25% |
| Soma dos conjuntos de trabalho dos processos¹, MiB | 5150,6Base | 3477,7Δ −1672,9−32,48% | 2890,6Δ −2260,0−43,88% | 2202,8Δ −2947,8−57,23% |
| Soma do commit dos processos¹, MiB | 2847,4Base | 1796,3Δ −1051,1−36,91% | 1587,9Δ −1259,5−44,23% | 1223,9Δ −1623,5−57,02% |
| Descritores dos processos¹ | 68 628Base | 45 867Δ −22 761−33,17% | 39 888Δ −28 740−41,88% | 30 597Δ −38 031−55,42% |
| DPC / s | 1210,5Base | 277,5Δ −933,0−77,08% | 216,7Δ −993,7−82,09% | 108,8Δ −1101,7−91,01% |
| Interrupções de hardware (ISR) / s | 922,1Base | 86,5Δ −835,6−90,62% | 64,3Δ −857,8−93,03% | 46,8Δ −875,3−94,93% |
| Hard faults durante o intervalo² | 636Base | 5258Δ +4622+726,73% | 1040Δ +404+63,52% | 1203Δ +567+89,15% |
| Leitura do disco, MiB | 12,90Base | 105,32Δ +92,42+716,28% | 81,50Δ +68,60+531,64% | 9,83Δ −3,07−23,78% |
| Escrita no disco, MiB | 214,57Base | 317,84Δ +103,27+48,13% | 86,97Δ −127,60−59,47% | 31,03Δ −183,54−85,54% |
| Inclui escrita de ficheiros WPR³, MiB | 164,00Base | 172,00Δ +8,00+4,88% | 72,00Δ −92,00−56,10% | 15,00Δ −149,00−90,85% |
| Operações de leitura do disco | 634Base | 5281Δ +4647+732,97% | 4241Δ +3607+568,93% | 836Δ +202+31,86% |
| Operações de escrita no disco | 5690Base | 2410Δ −3280−57,64% | 1250Δ −4440−78,03% | 1783Δ −3907−68,66% |
| Duração do intervalo, s | 299,986 | 299,999 | 300,006 | 300,016 |
Por baixo de cada valor é apresentada a Δ em relação a Clean na mesma fase: diferença absoluta nas unidades da linha e variação relativa em percentagem. Para a utilização de CPU, a diferença absoluta é indicada em pontos percentuais (p.p.). O sinal de menos indica uma redução do valor; o sinal de mais, um aumento. A duração da janela é apresentada sem delta. Fórmulas: Δ = этап − Clean, Δ% = (этап / Clean − 1) × 100.
A CPU é calculada com base em amostras CPU Usage (Sampled), tendo em conta a duração dos intervalos e calculando a média dos 16 processadores lógicos. A estimativa do tempo de CPU é igual à utilização média × duração da janela × 16 / 100. O pico é obtido a partir de intervalos de cerca de um segundo; os intervalos extremos podem ser mais curtos. Os eventos são contabilizados dentro da janela completa; os processos e threads correspondem ao seu final, excluindo Idle. Os arranques contabilizam a criação repetida do mesmo processo.
¹ Memória e identificadores: captura dos contadores dos processos no fim do ETL, 0,28–0,65 s após o marcador final. O desfasamento exato foi guardado em JSON. A soma dos conjuntos de trabalho volta a contar as páginas partilhadas e não é igual à RAM física ocupada. O commit dos processos indica a memória virtual alocada que tem de ser suportada por RAM ou pelo ficheiro de paginação; não corresponde à quantidade efetivamente escrita no ficheiro de paginação. Estas somas não descrevem toda a memória do kernel, dos controladores e da cache de ficheiros.
² Hard faults significam o carregamento a partir do disco de uma página ausente da RAM, incluindo páginas de ficheiros. Não são erros de memória de hardware. DPC e ISR indicam a frequência dos eventos, não a latência de entrada nem a duração do respetivo processamento.
³ A gravação WPR é identificada pelos nomes dos ficheiros dos registadores. Já está incluída na gravação total em disco. As métricas de disco incluem a atividade da ferramenta de medição e não constituem uma estimativa isolada da carga das aplicações.
Na comparação entre Clean e Expert Hardcore, a utilização de CPU por amostragem após o início de sessão diminuiu aproximadamente 5,3 vezes e, durante o período de inatividade, 6,8 vezes. As mudanças de contexto durante o período de inatividade diminuíram aproximadamente 5,8 vezes; número de processos no fim da janela: 153 → 64. Estas são relações entre métricas medidas específicas, não um coeficiente único de «aceleração do Windows».
Porque é que Safe teve maior atividade durante o período de inatividade
Seção intitulada “ Porque é que Safe teve maior atividade durante o período de inatividade”No último minuto do período de inatividade de Safe, estavam em execução mscorsvw.exe e ngen.exe. mscorsvw.exe representou cerca de 56,4 segundos de CPU. CPU média por minuto: 0,40 → 0,20 → 0,19 → 0,19 → 7,49%. Como resultado, a janela completa teve mais atividade do que Clean, embora os primeiros quatro minutos tenham sido mais tranquilos.
Este pico foi mantido na tabela principal. Com base numa única série sequencial, não é possível separar o efeito persistente do modo das tarefas pontuais em segundo plano e das alterações do estado do Windows ao longo do tempo.
Como interpretar as métricas de memória e disco
Seção intitulada “ Como interpretar as métricas de memória e disco”A gravação total em disco inclui a gravação do próprio WPR. Por exemplo, durante o período de inatividade de Clean, dos 214,57 MiB gravados, 164 MiB corresponderam diretamente aos ficheiros dos registadores WPR. Esta parte é apresentada numa linha separada da tabela. A pasta de teste encontrava-se no OneDrive; o efeito da sincronização não foi isolado separadamente. A velocidade da rede e o consumo de energia não são comparados nesta publicação.
CS2: FPS e tempo de fotograma
Seção intitulada “ CS2: FPS e tempo de fotograma”| Indicador | Clean | Safe Advanced | Advanced Advanced | Expert Hardcore |
|---|---|---|---|---|
| FPS médio | 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% baixo: média dos fotogramas lentos, FPS | 275,50Base | 283,63Δ +8,14+2,95% | 283,41Δ +7,91+2,87% | 288,21Δ +12,71+4,61% |
| Tempo médio de fotograma, ms | 1,126Base | 1,097Δ −0,028−2,51% | 1,093Δ −0,032−2,87% | 1,101Δ −0,025−2,18% |
| P99 do tempo de fotograma, ms | 3,370Base | 3,285Δ −0,085−2,53% | 3,241Δ −0,129−3,84% | 3,204Δ −0,167−4,95% |
| Diferença média entre fotogramas consecutivos, ms | 0,351Base | 0,338Δ −0,013−3,64% | 0,335Δ −0,016−4,53% | 0,329Δ −0,022−6,30% |
| FPS médio: intervalo das duas execuções | 884,85 – 891,72 | 908,79 – 913,59 | 914,55 – 914,57 | 907,57 – 908,59 |
Advanced Advanced obteve o FPS médio mais elevado: 914,56 contra 888,29 de Clean, +2,96%. Expert Hardcore ficou ligeiramente abaixo no FPS médio, mas apresentou o P1 mais elevado: 312,15 contra 296,73, +5,20%. A etapa mais agressiva não foi a melhor em todas as métricas.
O FPS médio de cada execução é igual a 1000 / среднее время кадра в мс. P1 é igual a 1000 / P99 времени кадра; P99 é calculado por interpolação linear dos fotogramas ordenados. Os resultados de cada etapa são as médias de dois resultados. Por baixo dos valores são apresentadas as diferenças absolutas e relativas em relação a Clean. Para FPS, um valor mais elevado significa maior rapidez; para o tempo de fotograma, um valor mais baixo significa maior rapidez. A linha 1% low é calculada separadamente como 1000 / среднее время самых медленных 1% кадров e não coincide com P1.
Todas as oito execuções e os fotogramas longos
| Etapa / execução | Fotogramas | FPS médio | P1 FPS | P99, ms | Fotograma mais longo, 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 |
Todos os intervalos entre fotogramas são positivos e a sequência temporal é monotónica. Os fotogramas longos foram mantidos. Os fotogramas não são repetições independentes da experiência: foram realizadas apenas duas execuções de FPS por etapa. O intervalo na tabela mostra a variação entre estas duas execuções, não um intervalo de confiança.
A utilização média da GPU foi de cerca de 74–76%, com picos até 95–96%. Estes dados não permitem afirmar que todas as partes do cenário são exclusivamente limitadas pela CPU. O campo PcLatency do CapFrameX não é utilizado como latência física de «movimento do rato → luz no ecrã».
Frametime Variance: uniformidade dos fotogramas
Seção intitulada “ Frametime Variance: uniformidade dos fotogramas”Foi utilizado o princípio do separador Variances do CapFrameX: módulo da diferença entre os tempos de dois fotogramas consecutivos |tᵢ − tᵢ₋₁|, em milissegundos. Os pares são distribuídos por cinco intervalos: <2, 2–<4, 4–<8, 8–<12 e ≥12 мс. Este indicador mede as variações entre fotogramas consecutivos; não é calculada aqui a variância estatística em ms². Os limites dos intervalos foram verificados com base no código-fonte do CapFrameX v1.8.6.
Em Expert Hardcore, a proporção de pares com uma diferença a partir de 2 ms é de 4,091% contra 5,879% em Clean. Isto corresponde a −1,787 p.p., ou −30,4% em relação a Clean. Em Safe Advanced, a redução é de 18,0%; em Advanced Advanced, de 26,1%. Estas percentagens dizem respeito à proporção de variações consecutivas a partir de 2 ms, não ao aumento do FPS nem à precisão da pontaria.
| Diferença entre fotogramas consecutivos | 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. |
Em cada etapa, são combinados os contadores de pares das duas execuções, sem ligar o último fotograma de uma execução ao primeiro da outra. O denominador é igual à soma de N − 1 nas duas execuções. Por isso, as proporções são ponderadas pelo número de pares, ao contrário da média dos dois valores de FPS. Os valores exatos são guardados em JSON e CSV; a tabela arredonda as proporções a quatro casas decimais. O CapFrameX arredonda-as mais cedo, pelo que os últimos algarismos apresentados podem diferir.
A principal redução ocorre no intervalo 2–<4 ms. A proporção de variações 4–<8 ms em Expert Hardcore é ligeiramente superior à de Clean: 0,0210% contra 0,0166%. Todos os intervalos foram mantidos, incluindo as variações raras. Com duas execuções, não é possível determinar se esta alteração é reproduzível.
O que significa para a pontaria: neste benchmark, os intervalos entre fotogramas tornaram-se mais uniformes para o limiar de 2 ms. Um possível benefício para a suavidade visual do movimento da mira continua a ser uma hipótese: a gravação dos intervalos entre fotogramas não mede a precisão da pontaria, o movimento do rato nem a latência até à apresentação da imagem. Não é possível prometer uma «pontaria muito melhor» com base nesta série.
Conclusão e limites do resultado
Seção intitulada “ Conclusão e limites do resultado”Nesta série sequencial, foi registada uma redução da atividade em segundo plano após o início de sessão. No cenário de CS2 selecionado, as três etapas seguintes apresentaram um FPS médio superior ao do Clean preparado. Resultado prático neste sistema de teste: cerca de 2–3% de FPS médio, sendo que Advanced e Expert Hardcore têm pontos fortes diferentes.
O estudo não determina o contributo de cada definição individual, a dimensão universal do aumento, o tempo de arranque do Windows nem a latência física de entrada. Expert Hardcore inclui uma alteração do plano de energia, pelo que é comparada a etapa completa. A redução do número de processos não é, por si só, uma medida do desempenho em jogos.
Limitações: um PC, ordem fixa das etapas, uma gravação WPR concluída por etapa, duas execuções de FPS, início manual da captura, compilação Debug sem hash do ficheiro binário guardado. Os efeitos da ordem, do aquecimento das caches e da manutenção em segundo plano não foram separados dos efeitos da otimização. Durante o período de inatividade de Clean, também houve um breve arranque do Task Manager; a janela completa foi mantida, sem remover qualquer segmento. Esta série não inclui reprodução independente nem reposição de controlo para Clean.
Antivírus e FPS
Seção intitulada “ Antivírus e FPS”Não se recomenda desativar o antivírus para aumentar o FPS. Esta série compara conjuntos de alterações completos: não foi realizado aqui um teste com a única variável «proteção ativada / desativada». Por isso, não demonstra que o antivírus não tenha qualquer efeito no FPS nem mede separadamente a memória poupada ao desativá-lo.
A Microsoft recomenda manter a proteção em tempo real ativada. Em caso de carga significativa, está disponível a análise de desempenho do Microsoft Defender, que permite identificar a causa específica.
Reposição do estado
Seção intitulada “ Reposição do estado”A reposição do estado original após Expert Hardcore não foi testada no âmbito destas medições. Para repetir o teste com estados independentes, deve ser restaurada uma imagem Clean preparada previamente e documentada a reposição. As limitações gerais da reversão estão descritas nos limites de recuperação do BoosterX.
Dados de origem e novo cálculo
Seção intitulada “ Dados de origem e novo cálculo”8 ETL · 8 CapFrameX JSON · tabelas, gráficos e scripts de recálculo. Para ver os resultados, abra README.html dentro do arquivo. As gravações originais foram preservadas sem alterações. Os dois ficheiros com o nome infinst.exe também fazem parte do teste CS2.
SHA-256 do arquivo7f20104f7eb46428e5e4f383515653b1320827be39fc171d1b5590210d0fbcdd
WPR, CSV · Todas as execuções de FPS, CSV · Frametime Variance, CSV · Cálculos, JSON · Script de recálculo
Num único arquivo foram reunidos os diretórios de origem das quatro etapas WPR concluídas, a tentativa incompleta de Expert Hardcore, os oito ficheiros JSON originais do CapFrameX, os scripts de gravação utilizados, a metodologia, as tabelas, os gráficos e o código-fonte do novo cálculo. Os antigos testes smoke e os arquivos de serviço que os duplicavam não foram incluídos. A presença de um estado de verificação antigo nos diretórios de origem não altera os cálculos aqui apresentados a partir do ETL.
Para analisar os ETL de forma independente, é necessário o Windows Performance Toolkit; para as gravações de jogo originais, pode ser utilizado o CapFrameX. O script analysis/analyze.py utiliza Python 3 e WPT 10+, não inicia gravações nem altera o sistema. As instruções estão no README.html. As somas de verificação permitem confirmar que os ficheiros não foram alterados; não comprovam as condições em que a experiência foi realizada.
Os rastos do sistema foram preservados no formato original: contêm informações técnicas sobre a instalação de teste, incluindo processos, caminhos locais e identificadores do sistema. O arquivo não é apresentado como anonimizado. O código-fonte da aplicação BoosterX e os ficheiros executáveis de terceiros não estão incluídos.
Fontes e histórico
Seção intitulada “ Fontes e histórico”- As gravações de origem desta série e o script de novo cálculo estão disponíveis acima.
- CS2 FPS BENCHMARK DUST2: descrição e limitações do mapa.
- Microsoft: CPU Analysis, amostras de CPU e mudanças de contexto.
- Microsoft: xperf cswitch e limites temporais.
- Microsoft: recomendações para a proteção permanente do Defender.
- Microsoft: contadores de memória do processo.
- CapFrameX: separador Variances e comparação de distribuições.
- CapFrameX v1.8.6: cálculo original de Frametime Variance.
- Metodologia geral de investigação da Wiki.
Última verificação: 2026-10-25. Primeira edição de 24 de outubro: quatro etapas num único PC físico, medições de origem abertas e novo cálculo. Em 25 de outubro, foram adicionadas as diferenças em relação a Clean, a tabela de FPS alargada e Frametime Variance. O estudo foi preparado pelo programador do BoosterX. Para verificação independente, foram publicadas as gravações de origem, as condições do teste e o script de novo cálculo.