Profiling em Go: como benchmarks, pprof e flame graphs revelam gargalos reais

A GopherCon 2026 traz na agenda oficial um workshop de meio período chamado "Half-Day Workshop: Profiling and Optimizing Go Programs", conduzido por Cory LaNou (Gopher Guides). A descrição pública da palestra é um bom pretexto para revisar um assunto que costuma intimidar mesmo quem já escreve Go há anos: o ferramental de profiling embutido na linguagem é excelente, mas saber quando e como usar cada peça é a parte difícil.

O problema que o tema ataca

Go entrega, direto na toolchain, benchmarks integrados ao go test, o pprof (mantido pelo Google) e a geração de flame graphs. Segundo a própria descrição do workshop, o obstáculo raramente é a falta de ferramenta: é entender a saída delas e escolher o profile adequado ao sintoma. É comum o desenvolvedor abrir um profile de CPU quando o gargalo era alocação de memória, ou tentar otimizar um trecho que nem aparece no caminho quente.

A lógica proposta é a que qualquer engenheiro de performance defende, independentemente de linguagem: medir antes de mexer. Otimização baseada em palpite tende a complicar o código e mover o ponteiro para o lado errado.

Começar pelo benchmark

O ponto de partida sugerido é o benchmarking. Em Go isso vive junto dos testes:

func BenchmarkParse(b *testing.B) {
    for i := 0; i < b.N; i++ {
        Parse(input)
    }
}

Rodando com go test -bench=. -benchmem você já vê tempo por operação e alocações. O benchmark serve a dois propósitos: dar uma linha de base e, depois, provar que a mudança realmente melhorou algo. Sem essa verificação, refatoração de performance vira fé.

A partir do benchmark dá para gerar profiles direto:

go test -bench=. -cpuprofile cpu.out -memprofile mem.out
go tool pprof cpu.out

Os profiles do pprof e quando usar cada um

O pprof produz tipos diferentes de profile, e a descrição do workshop enfatiza justamente saber qual escolher:

• CPU: onde o tempo de processamento está sendo queimado. Bom para loops caros, parsing, serialização.
• Heap/memória: quem aloca e o que sobrevive. Útil quando o problema é pressão de GC ou consumo crescente.
• Block e mutex: contenção de goroutines, espera em locks e canais. O suspeito quando a CPU está ociosa mas a latência é alta.
• Goroutine: fotografia do que está rodando ou preso.

Escolher o profile errado é a forma mais rápida de perder uma tarde olhando para o gráfico que não descreve o seu problema.

Flame graphs e profiling em produção

O workshop também cobre os chamados torch graphs (flame graphs) e a geração de profiles contra serviços HTTP em execução. Esse é o ponto que separa o exercício de laboratório do trabalho real: expor o endpoint net/http/pprof numa aplicação viva e coletar amostras sob carga costuma revelar gargalos que o benchmark isolado nunca mostra, porque dependem de concorrência, cache frio ou padrões de tráfego.

O flame graph ajuda porque comprime a call stack numa imagem em que a largura de cada barra representa tempo. Barra larga no topo, função folha cara. Barra larga na base que se espalha, caminho quente com muita ramificação. É leitura visual, não tabela.

Trade-offs que valem lembrar

Um alerta pragmático, que o material não precisa dizer para ser verdade: profiling tem custo e contexto.

• Nem todo código precisa disso. Otimizar um handler chamado dez vezes por dia é desperdício de engenharia. Profiling se paga em caminho quente e em serviço sob carga.
• Profile em produção adiciona overhead. O do CPU amostra e é barato; block e mutex podem pesar mais. Ligue com critério.
• Micro-otimização engana. Um benchmark verde num trecho que representa 2% do tempo total não muda a experiência de ninguém. A regra é atacar o que domina o profile.
• Legibilidade é moeda. Trocar código claro por versão obscura e 3% mais rápida raramente compensa fora de hot paths comprovados.

Para quem quiser se preparar para o tema, os pré-requisitos listados na agenda são bem-vindos como roteiro de estudo: fundamentos de Go (Go Tour, Go by Example), familiaridade com testes e um ambiente com Go 1.25 ou superior. O workshop exige ticket separado no evento, mas o fluxo que ele organiza (benchmark, profile, correção, verificação) vale como método mesmo para quem não vai à sala.

Fonte: Agenda oficial — Meeting Room 435, Level 4, SCC | Summit