Idle silencioso: fundo do Windows antes e depois da otimização
Nesta página
Resposta curta
Seção intitulada “Resposta curta”Desativar componentes em segundo plano do Windows torna de facto o sistema inativo mais silencioso: em duas séries independentes de medições, o número de processos caiu 49–56 %, a ocupação da CPU em inatividade — 17–67 %, e o volume de compromissos de memória (commit) — 52 % na segunda série. Mas sob carga total da CPU, o débito aumentou apenas 0,2–0,5 %. «Inatividade silenciosa» é uma redução confirmada do trabalho em segundo plano e da concorrência por recursos, e não um aumento de FPS: o efeito final em jogos não foi medido neste estudo.
Estado: a direção do efeito foi reproduzida em duas séries independentes na mesma compilação do Windows 11 numa máquina virtual. Os valores entre séries diferem porque o trabalho em segundo plano do Windows surge em picos: numa janela com análise do Microsoft Defender, a diferença de ocupação da CPU chega a −67 %, numa janela já silenciosa — −17 %.
Afirmação verificável
Seção intitulada “Afirmação verificável”Verificámos quatro afirmações:
- Desativar componentes em segundo plano reduz visivelmente a atividade do sistema em inatividade.
- Reduz visivelmente a atividade nos primeiros minutos após o arranque.
- Reduz visivelmente o consumo de memória.
- Proporciona um ganho de desempenho mensurável sob carga total da CPU.
Âmbito do estudo
Seção intitulada “Âmbito do estudo”- Windows 11 Pro, build 26300.9457 (26H2);
- máquina virtual: 4 vCPU, 8 GB de RAM, virtualização VMware;
- dois estados da mesma instalação: original («antes») e após aplicar o perfil de otimização do BoosterX (compilação atual à data das medições);
- duas séries independentes de medições: 2026-09-18 e 2026-09-19; os estados foram comparados em cópias independentes do disco, para que as medições não se influenciassem mutuamente;
- fases: 5 minutos após o arranque, 5 minutos de estabilização, 5 minutos de inatividade;
- cargas sintéticas curtas: 1, 4 e 8 threads, carga sobre a memória, carga com cadência e misturas de prioridades.
As medições não incluíram jogos reais, carga de GPU, hardware físico nem janelas longas (horas e dias).
Metodologia
Seção intitulada “Metodologia”O protocolo corresponde a «Como investigamos o Windows»:
- cada fase foi registada com uma trace ETW (Windows Performance Recorder, perfis leves de CPU, disco, ficheiros e rede) e contadores de desempenho com intervalo de 5 segundos (sistema) e 15 segundos (por processos);
- a fase «após o arranque» foi iniciada com um reinício controlado e ativada com um uptime de cerca de um minuto;
- em cada trace foi verificado o número de eventos perdidos — em todas as janelas apresentadas é igual a zero;
- a média foi calculada apenas sobre intervalos completos de cinco segundos dentro dos limites da fase (59 intervalos por fase);
- na série 2, a primeira execução «antes» foi excluída devido à entrada da máquina virtual em suspensão; foi utilizada a repetição;
- as provas de carga foram executadas duas vezes, apresentam-se as medianas; a ocupação da CPU foi normalizada para quatro vCPU.
«Antes» e «depois» são estados da mesma instalação do Windows: «depois» foi obtido aplicando o perfil de otimização, «antes» é o estado original. O conjunto de definições foi alterado como um todo, pelo que a contribuição isolada de cada desativação individual não foi avaliada.
Resultados
Seção intitulada “Resultados”Inatividade
Seção intitulada “Inatividade”Série 1 (2026-09-18) — inatividade consolidada sem manutenção ativa:
| Métrica | Antes | Depois | Alteração |
|---|---|---|---|
| Ocupação da CPU, % | 2,48 | 2,06 | −17 % |
| DPC + ISR, % CPU | 1,73 | 1,59 | −8 % |
| Mudanças de contexto, /s | 469 | 381 | −19 % |
| Processos (média) | 134,9 | 69,3 | −49 % |
| Threads (média) | 1 444,6 | 738,7 | −49 % |
| CPU total de todos os processos, % | 1,22 | 1,06 | −13 % |
| Memória disponível, MB | 5 490 | 6 518 | +1 028 |
| Leitura do disco, KB/s | 22,6 | 24,4 | +8 % |
| Escrita no disco, KB/s | 311,3 | 262,1 | −16 % |
| Rede (receção), KB/s | 132,6 | 2,2 | −98 % |
| Rede (envio), KB/s | 43,2 | 4,7 | −89 % |
Série 2 (2026-09-19) — a mesma janela de inatividade, mas no estado «antes» decorria uma análise em segundo plano do Microsoft Defender:
| Métrica | Antes | Depois | Alteração |
|---|---|---|---|
| Ocupação da CPU, % | 33,37 | 11,03 | −67 % |
| Mudanças de contexto, /s | 3 737 | 291 | −92 % |
| Processos (média) | 142,3 | 61,9 | −56 % |
| Threads (média) | 1 494,7 | 637,1 | −57 % |
| Memória disponível, MB | 5 174 | 6 653 | +1 479 |
| Memória física ocupada, MB | 3 017 | 1 538 | −49 % |
| Compromissos de memória (commit), MB | 2 617 | 1 249 | −52 % |
| Nonpaged pool, MB | 298,2 | 212,9 | −29 % |
| Paged pool, MB | 258,5 | 86,0 | −67 % |
| DPC, % CPU | 0,89 | 0,19 | −78 % |
| Leitura do disco, MB/s | 7,42 | 0,01 | −99,9 % |
| Escrita no disco, MB/s | 4,57 | 0,23 | −95,0 % |
Na inatividade da série 2 quase não houve rede em ambos os estados (dezenas de bytes por segundo), pelo que as linhas de rede não são apresentadas para ela. A diferença entre séries não é uma contradição, mas uma propriedade do próprio fundo: quando o Windows realiza manutenção, desativar componentes em segundo plano poupa mais; quando a janela já está silenciosa — menos.
Primeiros minutos após o arranque
Seção intitulada “Primeiros minutos após o arranque”| Métrica | Série 1 (antes → depois) | Série 2 (antes → depois) |
|---|---|---|
| Ocupação da CPU, % | 3,42 → 2,59 | 14,62 → 11,88 |
| Mudanças de contexto, /s | 1 114 → 600 | 1 257 → 393 |
| Processos | 132 → 74 | 139 → 64 |
| Threads | — | 1 719 → 746 |
| Memória física ocupada, MB | — | 2 821 → 1 581 |
| Memória disponível, MB | — | 5 370 → 6 610 |
| Leitura do disco, KB/s | — | 826 → 433 |
| Escrita no disco, KB/s | 634 → 418 | 709 → 298 |
| Rede (receção), KB/s | — | 1,15 → ~0 |
O travessão significa que nessa série a métrica não foi registada para a fase.
Composição e memória
Seção intitulada “Composição e memória”Instantâneo do inventário em inatividade (série 1):
| Antes | Depois | |
|---|---|---|
| Processos | 136 | 70 |
| Threads | 1 679 | 842 |
| Working set total, MB | 3 841 | 1 868 |
| Private bytes totais, MB | 1 524 | 660 |
Os maiores consumidores de memória antes da otimização: o processo antivírus MsMpEng.exe (257 MB), explorer.exe (213 MB), StartMenuExperienceHost (144 MB), msedge.exe (133 MB), SearchHost.exe (122 MB). Após a otimização, a lista passou a ser encabeçada por explorer.exe (170 MB), msedgewebview2 (119 MB), SearchHost.exe (115 MB) e StartMenuExperienceHost (106 MB).
A memória disponível aumentou 1,0–1,5 GB, e o volume de compromissos (commit) diminuiu 52 %. O que disto pode realmente ser «libertado» e porque a soma do working set dos processos não é o mesmo que memória livre é analisado em «Quanta memória se pode realmente libertar no Windows».
Sob carga total
Seção intitulada “Sob carga total”Provas sintéticas curtas (série 2, medianas de duas repetições):
| Cenário | Alteração do débito | Ocupação da CPU: antes / depois |
|---|---|---|
| Um thread | +5,4 % | 21,9 / 22,6 % |
| Quatro threads (total) | +0,19 % | 88,9 / 89,4 % |
| Oito threads (total) | +0,50 % | 88,9 / 88,8 % |
| Carga sobre a memória | +11,2 % | 84,8 / 87,5 % |
| Com cadência (pausas de 1 ms) | +5,4 % | 64,3 / 67,7 % |
| Prioridades mistas | +8,5 % | 21,2 / 22,5 % |
| Prioridade em segundo plano | +77,1 % | 38,8 / 65,2 % |
Sob carga total de quatro threads, o processo útil recebeu cerca de 89 % da capacidade de quatro vCPU, tanto antes como depois da otimização. Os ~11 % restantes na máquina virtual não podem ser declarados «ruído do Windows» eliminável: o escalonamento do hipervisor não é visível a partir da trace do convidado. As threads de trabalho distribuíram-se uniformemente (variação do volume de trabalho entre elas — 0,994–0,997), não se observou inanição, e a fila da CPU em inatividade após a otimização está praticamente vazia.
Para onde vai o fundo
Seção intitulada “Para onde vai o fundo”Fontes medidas de atividade em segundo plano no estado «antes»:
- a análise antivírus — a principal fonte na janela da série 2: o processo
MsMpEng.execonsumiu 212 segundos de CPU numa janela de cinco minutos de inatividade; - no estado original funcionavam o serviço de pesquisa, o serviço SysMain, a telemetria, o gestor de impressão e outros componentes — o perfil de otimização coloca cerca de 50 serviços em segundo plano e 58 tarefas agendadas no estado desativado;
- após o arranque, a atividade acompanha o orquestrador de atualizações do Windows.
Desativar componentes em segundo plano não elimina o fundo por completo: no estado otimizado continuava a funcionar a avaliação de compatibilidade de aplicações (cerca de 3,7 ms de CPU por segundo na janela de manutenção), e o fundo residual total em inatividade consolidada foi de 4,8 ms de CPU por segundo — cerca de 0,12 % da capacidade de quatro vCPU (medido por trace).
O que foi confirmado
Seção intitulada “O que foi confirmado”- Reproduzido (duas séries independentes): número de processos −49…−56 %, threads −49…−57 %, memória disponível +1,0–1,5 GB.
- Medido (série 2): commit −52 % em inatividade; memória física ocupada −49 % em inatividade e −44 % na fase após o arranque.
- Medido: ocupação da CPU em inatividade −17 % numa janela silenciosa e −67 % numa janela com análise; mudanças de contexto −19 % e −92 %; DPC −78 % (janela da série 2); atividade após o arranque mais baixa em ambas as séries.
- Medido: sob carga total da CPU, ganho de débito +0,19 % (4 threads) e +0,50 % (8 threads); sob carga parcial e mista — de +5,4 a +11,2 %.
- Medido: a carga da classe de prioridade em segundo plano acelerou 77,1 % — no estado «antes» competia com o trabalho em segundo plano do próprio Windows, incluindo a análise antivírus.
- Observado: as principais fontes de fundo — a análise antivírus, a manutenção e as tarefas de compatibilidade; após a otimização, o fundo residual é próximo de zero, mas não nulo.
O que não foi confirmado
Seção intitulada “O que não foi confirmado”- Ganho de FPS, redução do input lag ou do frametime em jogos reais: não foi medido. As provas sintéticas de CPU não modelam um jogo com GPU e não provam o efeito em jogos.
- A contribuição isolada de cada desativação individual: foi aplicado um conjunto de alterações.
- A transposição dos valores absolutos para hardware físico, outras compilações e outros perfis de otimização.
- A estabilidade em janelas longas: cada fase tem 5 minutos; o trabalho em segundo plano do Windows surge em picos, pelo que o «dia médio» não foi medido.
Limitações
Seção intitulada “Limitações”- As medições foram realizadas numa máquina virtual. A virtualização introduz a sua própria quota de DPC/ISR e oculta o escalonamento do anfitrião; em hardware físico os valores absolutos serão diferentes. As proporções e a direção da comparação «antes/depois» em condições idênticas mantêm-se.
- A métrica ISR foi excluída das tabelas: numa máquina virtual, o contador ISR por PDH diverge dos processadores de interrupção por ETW em cerca de 10 % e não converge numa soma exata.
- A janela «antes» da série 2 continha uma análise ativa do Defender, e a carga do anfitrião entre janelas era diferente (em média 44 % contra 24 %). Por isso, os valores estão ligados a janelas concretas; a direção foi confirmada por duas séries.
- Na série 1, parte da fase de inatividade foi interrompida por uma pausa externa da máquina virtual de cerca de 26 segundos; a captura terminou após o reinício, sem eventos perdidos.
- As provas de carga — duas repetições: é estatística descritiva, a significância estatística não foi avaliada.
- Parte do ganho em inatividade está relacionada com a desativação de componentes de proteção do Microsoft Defender. Um sistema sem proteção antivírus é um compromisso consciente, e não uma otimização sem custos; desativar a proteção deve ser feito compreendendo o preço.
- A camada de medição (trace e contadores) cria ela própria uma pequena carga em segundo plano; ela está presente em ambos os estados.
O estudo e as ferramentas utilizadas pertencem ao desenvolvedor do BoosterX, pelo que o desenvolvedor tem um interesse direto nos resultados. A metodologia e os limites de aplicabilidade estão descritos acima, e as conclusões podem ser verificadas pelos dados abertos e pelas fontes públicas enumeradas.
Conclusão prática
Seção intitulada “Conclusão prática”A redução do ruído de fundo é um efeito real, reproduzido duas vezes: metade dos processos e threads, metade dos compromissos de memória, uma ordem de grandeza menos de atividade de disco e de rede em inatividade. Isto é útil por si só — para a capacidade de resposta do sistema, tarefas em segundo plano, temperatura, ruído das ventoinhas e autonomia da bateria — e não exige promessas de FPS.
O que não se deve esperar disto: um ganho de desempenho sob carga total. Se a CPU já está carregada com trabalho útil a ~89 % da capacidade, desativar a atividade em segundo plano não acrescentará os 11 % restantes — numa máquina virtual eles não pertencem ao Windows. Quanto mais ocupado estiver o sistema no momento da comparação, maior será o efeito visível: numa janela de manutenção a diferença é múltipla, numa janela silenciosa — moderada.
Recomendação: avalie o fundo antes e depois de quaisquer alterações no seu computador (Gestor de tarefas → «Desempenho» e «Processos», Monitor de recursos), em vez de se orientar por percentagens alheias. Se o objetivo é o FPS num jogo concreto, meça exatamente isso antes e depois da alteração.
Restauro do estado
Seção intitulada “Restauro do estado”Ambas as séries foram realizadas em máquinas virtuais isoladas em cópias independentes do disco; após as medições, as máquinas foram devolvidas aos estados originais. O artigo não exige que o leitor altere parâmetros, pelo que não é necessária uma ação de restauro separada no computador do utilizador.
Fontes primárias públicas
Seção intitulada “Fontes primárias públicas”- Microsoft: Windows Performance Recorder — ferramenta de registo de traces ETW utilizada na metodologia; verificado em 2026-09-20.
- Microsoft: About Event Tracing — modelo ETW e verificação de eventos perdidos; verificado em 2026-09-20.
- Microsoft: Microsoft Defender Antivirus no Windows — processos e serviços do Defender, incluindo
MsMpEng.exe(«Antimalware Service Executable» no Gestor de tarefas); verificado em 2026-09-20. - Como investigamos o Windows — níveis de evidência e protocolo de medições.
- Service Host e componentes em segundo plano do Windows 11 — como o Windows distribui os serviços em segundo plano pelos processos.
- Quanta memória se pode realmente libertar no Windows — análise detalhada da memória deste mesmo experimento.
- Ambiente de trabalho contra ecrã de início de sessão — continuação: de que é composto o ruído da sessão do utilizador.
Histórico de alterações
Seção intitulada “Histórico de alterações”- 2026-09-20: primeira publicação — duas séries independentes de medições de inatividade, fases após o arranque, inventário e provas de carga.
- 2026-09-20: atribuição dos resultados por séries clarificada (commit e memória física ocupada — apenas série 2; processos −49…−56 %); a declaração sobre conflito de interesses foi trazida para a formulação canónica.