# Flame graphs gargalos: guia de análise em 5 passos > Flame graphs são ferramentas visuais que convertem call stacks em barras horizontais proporcionais ao tempo de execução. A análise de gargalos de CPU exige inspecionar a largura das barras da base ao topo, priorizando funções com maior área. Erros comuns incluem ignorar chamadas de sistema e confundir largura com frequência. A técnica permite identificar pontos de contenção diretamente na imagem. *PosUp · Apps e Software · 12 de agosto de 2026 · Patrícia Lemos* Flame graphs transformam call stacks em uma imagem onde a largura de cada barra representa tempo. Este guia mostra como usar essa visualização para encontrar gargalos de CPU, da base ao topo, com erros comuns a evitar. Flame graphs são uma das formas mais diretas de visualizar onde o tempo de CPU está sendo gasto. A largura de cada barra representa tempo de execução, e a pilha de chamadas aparece empilhada da base ao topo. Este guia mostra como analisar esses gráficos para identificar gargalos reais, sem se perder em detalhes irrelevantes. Para começar, você precisa de um flame graph gerado por uma ferramenta de profiling, como pprof (Go), perf (Linux) ou a saída de um profiler da sua linguagem. O gráfico mostra funções empilhadas: cada retângulo é uma função, e o retângulo acima é quem chamou a função de baixo. Barras largas significam mais tempo acumulado, seja em trabalho direto ou em chamadas para outras funções. ## Passo 1: Identifique as barras mais largas na base Comece pela base do gráfico. As barras mais largas representam as funções que consomem a maior parte do tempo total, incluindo tudo que elas chamam. Se uma barra ocupa mais de 30% da largura total, ela é um forte candidato a gargalo. Trace o caminho da base até o topo para entender a cadeia de chamadas. Erro comum: focar apenas nas barras do topo. Uma barra larga no topo pode ser uma função rápida chamada muitas vezes, mas o custo real pode estar na função que a chamou, na base. ## Passo 2: Analise as barras largas no topo Barras largas no topo, sem filhos, indicam trabalho direto da função, ou seja, CPU gasta dentro dela, sem chamadas. Se uma função no topo é larga, ela está fazendo processamento pesado. Compare com a base: se a mesma função aparece em vários caminhos, o gargalo pode ser a própria função. Dica: use a cor para distinguir funções do sistema vs. da aplicação. Funções do kernel, por exemplo, aparecem com cores diferentes em muitas ferramentas, o que ajuda a separar custo de sistema do custo da sua aplicação. ## Passo 3: Procure por "plataformas" altas e largas Uma plataforma é uma sequência de barras empilhadas, da base ao topo, que permanece larga em toda a altura. Isso indica um caminho de execução dominante, onde o tempo está concentrado. Quanto mais alta e larga a plataforma, mais crítico é o gargalo. Se a plataforma tem muitos níveis, a culpa pode estar em uma função específica no meio da pilha. Erro comum: tentar otimizar todas as funções largas de uma vez. Priorize a plataforma mais alta e larga, pois ela representa o maior ganho potencial com menor esforço. ## Passo 4: Compare flame graphs de cenários diferentes Um flame graph isolado mostra onde o tempo foi gasto, mas não prova que é um gargalo. Gere gráficos para cenários distintos: carga normal, pico de uso, ou após uma alteração de código. Compare as larguras relativas das mesmas funções. Se uma função cresce significativamente em um cenário, ela é o gargalo sob aquela condição. Dica: normalize os gráficos para o mesmo tempo total de execução, caso contrário, a comparação fica distorcida. A maioria das ferramentas permite exportar os dados crus para análise. ## Passo 5: Valide com um teste de hipótese Antes de otimizar, formule uma hipótese clara: "a função X é responsável por Y% do tempo". Use os números do flame graph para estimar o percentual. Depois, aplique uma mudança mínima, como caching ou redução de alocações, e gere um novo flame graph. Meça a diferença na largura da barra. Erro comum: otimizar sem medir depois. Se a barra não encolheu, a hipótese estava errada. Repita o ciclo com outra função. ## Checklist rápido - Identifiquei a barra mais larga na base e tracei a cadeia até o topo. - Verifiquei as barras largas no topo para trabalho direto. - Localizei a plataforma mais alta e larga como prioridade. - Comparei flame graphs de cenários diferentes e normalizei o tempo. - Formulei uma hipótese, apliquei uma mudança e re-medí com novo gráfico. ## FAQ ### O que significa a largura de uma barra em um flame graph? A largura de cada barra representa o tempo de CPU acumulado naquela função, incluindo o tempo gasto em funções chamadas por ela. Barras mais largas indicam maior consumo de tempo. A altura representa a profundidade da pilha de chamadas, não tempo. ### Por que devo ler o flame graph da base para o topo? A base mostra o ponto de entrada da execução, onde o tempo total é acumulado. Ler da base para o topo ajuda a entender a cadeia de chamadas e identificar onde o custo é originado. Barras largas na base indicam funções que dominam o tempo total. ### Como diferenciar trabalho direto de chamadas em um flame graph? Trabalho direto aparece como barras largas no topo, sem filhos abaixo delas. Chamadas aparecem como barras empilhadas, com a função chamadora abaixo. Se uma barra tem muitos filhos, o tempo está sendo gasto nas funções chamadas, não na própria barra. ### Qual a diferença entre flame graph e call tree? Flame graph é uma visualização agregada que mostra a distribuição de tempo em toda a execução, comprimindo a call stack em uma imagem. Call tree é uma estrutura hierárquica que mostra chamadas individuais, com tempos por chamada, útil para análise detalhada, mas menos visual. ### Como evitar falsos positivos ao analisar flame graphs? Gere flame graphs em múltiplas execuções e cenários para evitar amostras atípicas. Use um período de amostragem adequado ao perfil da aplicação. Compare com um baseline antes de concluir que uma função é um gargalo. Sempre valide com um teste de hipótese após a otimização. ### O que fazer se o gargalo estiver em uma função do sistema? Se a barra larga pertence a uma função do kernel ou biblioteca do sistema, o gargalo pode ser causado por chamadas de sistema frequentes, I/O ou contenção de locks. Nesse caso, revise o código da aplicação para reduzir essas chamadas, como usar buffers maiores ou evitar syscalls desnecessárias. --- Fonte (canonical): https://posup.com.br/apps-e-software/flame-graphs-gargalos-guia-de-analise-em-5-passos/