pc-perf-audit

pc-perf-audit - auditoria de performance medida, para qualquer PC

Destilado de meses de trabalho numa máquina real (Ryzen 7 5700X + RTX 2060, Valorant competitivo). Serve para qualquer jogo, qualquer CPU (Intel/AMD) e qualquer GPU (NVIDIA/AMD/Intel): o método é agnóstico; o que muda por jogo (exe, config, log, anti-cheat, cenário de reclamação) está em references/jogos.md. O que vale aqui é o método e o catálogo do que já foi medido; os números daquela máquina são exemplos, não receita para outra. Quando um exemplo citar Valorant, leia como "exemplo de um jogo".

Regras que valem mais que qualquer tweak

1. Você não decide o que é melhor para o dono. Você monta o teste. Hipótese, mudança reversível, ele joga, você colhe o veredito.
2. Dois tipos de veredito, nunca misturar:
   • Mensurável (frametime, 1% low, hitches, latência, estabilidade): decide o número.
   • Julgável (nitidez, contraste, som, "feel", visibilidade): decide só o dono, uma mudança por vez. Reporte as duas coisas separadas.
3. Uma variável por vez. Uma corrida só não decide nada. Mínimo duas corridas, descartar o aquecimento, olhar o desvio minuto a minuto, não só a média.
4. Não bateu a linha de base? Reverte. Ganho visual não compra queda de frametime (a menos que o dono diga o contrário, e mesmo assim meça e reporte o custo).
5. Caminho que não paga nada, sempre. Antes de propor algo que custa CPU/GPU/latência/risco, procure a mesma coisa numa camada mais perto da saída de vídeo ou que não cobra (ex.: vibrance digital no painel em vez de filtro por quadro; escalonar na GPU em vez de no monitor; limitador de FPS nativo do jogo em vez de limitador no driver; fechar app em vez de mexer em prioridade).
6. NUNCA conclua "a máquina está entregando o que pode". "Onde está o custo" e "dá para executá-lo mais rápido" são perguntas diferentes: código serial roda mais rápido com clock efetivo maior, latência de memória menor, menos disputa de cache.
7. Evidência antes de afirmação. Teoria plausível já derrubou várias rodadas. Não apresente hipótese como resultado, não declare ganho sem medição.
8. O instrumento também é carga. Medidor, coletor, vigia, overlay, e o próprio agente (Claude, terminal, PowerShell) gastam CPU. Durante uma captura: não use a máquina.
9. Quando a medição discorda do usuário por dias, suspeite da medição antes da percepção dele. Isso se repetiu 4 vezes (ver references/armadilhas.md).
10. Confirme só o que é arriscado ou irreversível (firmware, BIOS, segurança, apagar dados). O resto: escolha, diga o porquê em uma linha, siga.
11. Reversibilidade: antes de qualquer mudança, registre o valor original e o comando de desfazer. Nada de dry-run que deixa rastro; simulação não toca em disco.

Etapas (siga na ordem; cada uma tem critério de saída)

Etapa 0 - Perfil e objetivo (entrevista curta)

Pergunte (de uma vez, com AskUserQuestion, não em conversa longa):

• Jogo(s) principal(is), modo (competitivo/casual), meta (FPS alvo, taxa do monitor). Para cada jogo preencha a ficha de references/jogos.md (exe, API, engine, config, log, anti-cheat, modo de teste).
• Sintomas: microstutter, queda na troca de tiro, freeze total, BSOD, corte de áudio, input lag, cintilação/serrilhado, tela preta. Qual minuto/mapa/momento? (ancora a captura)
• Inegociáveis do dono (não se mexe nem se argumenta): sensibilidade, DPI, resolução, modo de tela esticado, mira, vibrance, apps que ele precisa abertos (ex.: Discord).
• O que ele já tentou e o que já ficou bom/ruim. Houve um dia "perfeito"? Quando?
• Anti-cheat do jogo (Vanguard, EAC, BattlEye, FACEIT): limita afinidade, prioridade, injeção de overlay e drivers de terceiros. Veja references/catalogo-alavancas.md sec. 11. Saída: perfil escrito no diário (modelo em references/template-diario.md).

Etapa 1 - Inventário (somente leitura)

Rode scripts/inventario.ps1 -Saida <pasta> (PowerShell 5.1, de preferência elevado; sem elevação alguns campos saem vazios e o script avisa). Ele coleta CPU, GPU, RAM (velocidade configurada x nominal, tensão), BIOS/placa, SO, plano de energia e EPP, MPO, HAGS, VBS/HVCI, Modo de Jogo, GameDVR, Secure Boot, Defender, serviços de update, NICs, discos, monitores, resolução/refresh, startup, serviços e processos de terceiros, overlays conhecidos, e contagem de eventos 6008/1001/WHEA. Leia inventario.txt e classifique a plataforma: CPU: AMD Zen2/3/4/5 (X3D?) | Intel Core híbrido (P+E) | Intel Core não-híbrido, GPU: NVIDIA | AMD | Intel Arc | iGPU. Isso escolhe as seções do catálogo. Saída: tabela "item -> valor -> normal? -> hipótese" no diário. Não mude nada ainda.

Etapa 2 - Higiene do ambiente (o que roda durante a partida)

Objetivo: ambiente de partida conhecido e limpo. Use o inventário + Get-Process.

• Liste o que consome CPU em segundo plano (navegador, launcher, cloud sync, updaters, overlays, RGB, capturadores, o próprio agente). Separe: fechar, impedir de nascer, deixar (decisão do dono).
• Prefira impedir de nascer (StartupApproved, política, permissão de segundo plano de app da Store) a matar a cada N minutos. Cheque se o item da sua lista casa de verdade com o nome do processo (um 'WhatsApp' que nunca casou WhatsApp.Root sobreviveu 17 dias).
• Updaters/serviços que religam sozinhos (Windows Update, vendor updaters): decida contenção e verifique que ela persiste (veja armadilhas: instalador recria tarefa/serviço).
• Overlays que injetam DLL no Present (RTSS/Afterburner OSD, Discord overlay, Steam, GeForce, Medal, OBS hook): custo pequeno mas na thread de render. Liste, não mate sem o dono saber; medir o efeito é opcional (nesta máquina o ganho não foi demonstrável). Saída: lista de "apps durante a partida" + mecanismo de contenção + como verificar.

Etapa 3 - Linha de base medida

Protocolo completo em references/metodo.md. Resumo:

1. Jogo fechado, máquina assentada (5+ min após boot), nada novo aberto.
2. scripts/capturar.ps1 -Processo <exe> -Segundos 420 -Rotulo <texto> durante uma partida real no modo/mapa de reclamação (DM descartável se o PresentMon for risco). A captura não analisa (análise em CPU/RAM durante a partida é carga).
3. Depois da partida, jogo fechado: python scripts/analisar-frametime.py <csv>.
4. Duas corridas no mínimo, mesmo mapa. A primeira após boot/patch/driver é fria.
5. Pergunte o veredito (nota/frase) e anote ao lado do número. Com 8+ capturas e vereditos, valide qual métrica correlaciona (posto) com o que ele sente e use essa. Saída: linha de base por cenário (DM e 5v5 são diferentes!) com hitches/min, pior quadro, 1%/0,1% low, p99, desvio por minuto, e o veredito dele.

Etapa 4 - Diagnóstico

Árvore em references/diagnostico.md. Perguntas na ordem:

1. CPU-bound ou GPU-bound? (MsCPUBusy vs MsGPUBusy, mediana e nos quadros ruins)
2. O problema é média ou cauda? (hitches/min, pior quadro, graves >20 ms)
3. Os hitches têm gatilho? (troca de round, carregamento, respawn, mapa, habilidade, fim de partida, patch/driver recente = shader recompilando) - cruze com o log do jogo.
4. Algo externo disputa? (traço de kernel/ETW; ISR/DPC; I/O de disco; memória livre; temperatura e clock) - só conclua com instrumento certo.
5. Se for freeze/BSOD/corte de áudio, é outra árvore (hardware/estabilidade/rádio). Saída: hipóteses ordenadas por (probabilidade x custo de testar x reversibilidade).

Etapa 5 - Alavancas (do mais barato ao mais caro)

Consulte references/catalogo-alavancas.md, só as seções da plataforma detectada, e a lista de refutados antes de propor qualquer coisa. Ordem de ataque:

1. Camada que não cobra: scanout/display (escala na GPU, vibrance digital, tempo de resposta do monitor), Windows (MPO, plano de energia/EPP, update contido, apps de fundo).
2. Velocidade do núcleo que roda a thread do jogo: EPP/boost, limites de energia, SMT/E-cores, latência e tensão de memória, FCLK/ring, Curve Optimizer/undervolt, resfriamento.
3. Estabilidade: tensão de memória, XMP/DOCP, BIOS, C-states, fonte, temperatura.
4. Config do jogo: só o que reduz CPU por personagem (sombras, corpos, contadores); respeitando os inegociáveis e o que é informação competitiva (som, sombra de inimigo).
5. Rede/áudio/periféricos: medir antes; tweaks de rede já pioraram 5x. Para cada alavanca: valor original, comando de aplicar, comando de desfazer, hipótese mensurável e o que o dono precisa julgar.

Etapa 6 - Teste A/B e veredito

Para cada alavanca (uma por vez): aplicar -> duas capturas no mesmo cenário -> comparar contra a linha de base do mesmo mapa/modo -> perguntar o que ele sentiu -> decidir: ADOTAR | REVERTER | SEM VEREDITO (mais dados). Registre mesmo as refutadas, com o número: a lista de refutados é o ativo mais valioso do projeto. Regra de comparação: filtre a linha de base pelo estado da máquina, não pela data. Se mexeu em algo entre duas corridas, a série virou anedota - refaça.

Etapa 7 - Congelar o estado aprovado

Quando o dono disser "tá bom, não quero que regrida": fotografe o estado (BIOS, drivers, serviços, tarefas, registro, energia, config do jogo, startup) numa lista de sondas com valor esperado, rode-a periodicamente e depois de patch/driver/BIOS. Regras:

• Antes de congelar, rode a comparação sem congelar e resolva cada desvio (deliberado -> congela; regressão -> conserta). Congelar com desvio grava a regressão como ouro.
• Congele com o jogo fechado e com a sessão elevada.
• Sonda que gera falso alarme ensina a ignorar sonda: investigue o histórico do valor.
• Sonda com nome/valor de chave errado é pior que sonda ausente: confira contra o arquivo real.
• Documente o que uma gravação de BIOS/CMOS zerado desfaz em silêncio (SMT, C-state, DOCP, tensão de DRAM, Secure Boot, Resizable BAR, PBO) e o roteiro de volta.

Etapa 8 - Documentação viva

Mantenha um diário (references/template-diario.md): estado atual, linha de base, lista de refutados, armadilhas pagas, pendências em ordem. Corrija entradas erradas com retratação explícita no topo, não apagando - o histórico de erros evita reincidência.

Como entregar resultados ao usuário

• Em pt-BR (ou o idioma do dono), direto. Uma linha de porquê por decisão.
• Tabela por captura: cenário, hitches/min, pior quadro, graves >20 ms, 1%/0,1% low, desvio, veredito dele. Separe "o que o número diz" de "o que só você pode dizer".
• Nunca reporte FPS por segundo fixo como "o que ele vê": o contador do jogo usa janela curta.
• Marque cada afirmação: MEDIDO, HIPÓTESE, LITERATURA (fonte), DECISÃO DO DONO.

Arquivos desta skill

• references/metodo.md - protocolo de captura, métricas, recortes, validação de métrica.
• references/jogos.md - ficha por jogo, marcadores de log, perfis por gênero/engine, o que é universal x específico.
• references/diagnostico.md - árvore de sintomas -> instrumento -> causa provável.
• references/catalogo-alavancas.md - tudo que foi tentado/medido, por camada e fabricante.
• references/armadilhas.md - erros de instrumento e de raciocínio que já custaram iteração.
• references/template-diario.md - modelo do diário/AGENTS.md da máquina auditada.
• scripts/inventario.ps1 - inventário somente leitura (PS 5.1, ASCII).
• scripts/capturar.ps1 - captura PresentMon sem analisar + snapshots de processos.
• scripts/analisar-frametime.py - análise offline robusta (Python 3 stdlib).