Performance no .NET com IA: medir, otimizar e provar com BenchmarkDotNet

A IA virou uma ótima companheira para revisar código. Peça para ela "melhorar a performance" de um método e, em segundos, você recebe uma lista de sugestões escritas com total confiança: use Span<T>, troque LINQ por for, adicione stackalloc, paralelize com Parallel.ForEach.

O problema é que confiança não é medição. Boa parte dessas sugestões não muda nada, algumas pioram e outras mudam o comportamento do sistema sem ninguém perceber.

Neste artigo, vou mostrar o método que uso para otimizar código .NET com ajuda da IA: medir antes, otimizar uma mudança por vez e provar depois. Tudo com um exemplo real, que saiu de 1,5 segundo para 12 milissegundos e de 33 MB para 0,23 MB de alocação.

O cenário

Um relatório de vendas comum: recebemos linhas de pedidos no formato PEDIDO;CLIENTE;SKU;QUANTIDADE;PRECO, somamos o total por cliente, ignoramos clientes bloqueados e retornamos os 10 maiores.

Esta é a versão original. Ela funciona, é legível e passaria tranquilamente em muitos code reviews:

public static List<ItemRelatorio> Gerar(string[] linhas, List<string> clientesBloqueados) { var pedidos = new List<Pedido>(); foreach (var linha in linhas) { var partes = linha.Split(';'); pedidos.Add(new Pedido( Numero: partes[0], Cliente: partes[1], Sku: partes[2], Quantidade: int.Parse(partes[3], CultureInfo.InvariantCulture), PrecoUnitario: decimal.Parse(partes[4], CultureInfo.InvariantCulture))); } var resultado = new List<ItemRelatorio>(); foreach (var cliente in pedidos.Select(p => p.Cliente).Distinct()) { if (clientesBloqueados.Contains(cliente)) continue; var total = pedidos .Where(p => p.Cliente == cliente) .Sum(p => p.Quantidade * p.PrecoUnitario); resultado.Add(new ItemRelatorio(cliente, total)); } return resultado .OrderByDescending(r => r.Total) .ThenBy(r => r.Cliente, StringComparer.Ordinal) .Take(10) .ToList(); } 

Com 100 mil linhas e 1.000 clientes, esse método leva mais de 1,5 segundo. Se você já sabe onde está o problema, ótimo. Mas o ponto aqui é o método, não o palpite.

Passo 1: medir antes de tocar no código

Antes de pedir qualquer coisa para a IA, crie um benchmark com o BenchmarkDotNet. Ele cuida de aquecimento, múltiplas execuções e estatística, coisas que um Stopwatch solto não resolve:

[MemoryDiagnoser] public class RelatorioBenchmark { private string[] _linhas = []; private List<string> _bloqueadosLista = []; private HashSet<string> _bloqueadosSet = []; [Params(10_000, 100_000)] public int Linhas { get; set; } [GlobalSetup] public void Setup() { _linhas = GeradorDeDados.GerarLinhas(Linhas, clientes: 1_000, seed: 42); _bloqueadosLista = GeradorDeDados.GerarBloqueados(50); _bloqueadosSet = new HashSet<string>(_bloqueadosLista, StringComparer.Ordinal); } [Benchmark(Baseline = true)] public List<ItemRelatorio> Original() => RelatorioOriginal.Gerar(_linhas, _bloqueadosLista); [Benchmark] public List<ItemRelatorio> Otimizado() => RelatorioOtimizado.Gerar(_linhas, _bloqueadosSet); } 

Dois detalhes importantes: o [MemoryDiagnoser] mostra quanto cada execução aloca de memória (em APIs com muita carga, alocação vira pressão no Garbage Collector), e o benchmark só vale em Release.

Passo 2: dar contexto para a IA, não só o código

A diferença entre uma sugestão genérica e uma análise útil está no contexto. No repositório, deixo um arquivo CLAUDE.md com as regras de performance do projeto:

## Regras para otimizações de performance - Nunca otimize sem medir antes. Todo gargalo precisa de um benchmark no BenchmarkDotNet. - Proponha uma mudança por vez e explique a complexidade (Big O) antes e depois. - O comportamento não pode mudar: a validação em Program.cs precisa continuar passando. - Considere alocações de memória, não só tempo ([MemoryDiagnoser]). - Não use unsafe, stackalloc ou paralelismo sem um benchmark que justifique. 

E o pedido para a IA vai junto com o resultado do benchmark:

Analise o método RelatorioOriginal.Gerar. Segue o resultado do BenchmarkDotNet. Liste as hipóteses de gargalo ordenadas por impacto estimado, com a complexidade de cada trecho. Proponha UMA mudança por vez. O resultado do relatório precisa continuar idêntico. 

Repare que não pedi "deixe mais rápido". Pedi hipóteses ordenadas, complexidade e uma mudança por vez. A IA responde muito melhor quando o pedido tem critério.

O que a análise encontrou

Três problemas, em ordem de impacto:

1. Complexidade O(clientes × pedidos). Para cada cliente distinto, o Where percorre todos os pedidos de novo. Com 1.000 clientes e 100 mil pedidos, são cerca de 100 milhões de comparações para algo que pode ser feito em uma única passada.
2. List.Contains para os bloqueados. Cada consulta é uma busca linear. Com um HashSet, a busca passa a ser O(1).
3. Split em todas as linhas. Cada Split cria um array e uma string por campo, inclusive para campos que nem usamos, como número do pedido e SKU.

Passo 3: uma mudança por vez, medindo cada uma

Aqui está a parte que mais gente pula. Aplicar tudo de uma vez até funciona, mas você não sabe qual mudança trouxe o ganho, e fica impossível justificar a complexidade extra de cada uma.

Etapa 1: uma única passada com Dictionary. Em vez de agrupar depois, acumulamos o total por cliente enquanto lemos as linhas. O algoritmo cai de O(clientes × pedidos) para O(pedidos).

Etapa 2: HashSet para os bloqueados. Uma linha de mudança, ganho garantido.

Etapa 3: parsing com ReadOnlySpan<char> e busca sem alocar strings. Em vez de Split, percorremos a linha como um span. E com o alternate lookup, disponível a partir do .NET 9, conseguimos consultar o HashSet e o Dictionary usando o próprio span, sem criar uma string para cada linha:

public static List<ItemRelatorio> Gerar(string[] linhas, HashSet<string> clientesBloqueados) { if (!clientesBloqueados.TryGetAlternateLookup<ReadOnlySpan<char>>(out var bloqueados)) throw new ArgumentException("Crie o HashSet com StringComparer.Ordinal.", nameof(clientesBloqueados)); var totais = new Dictionary<string, decimal>(StringComparer.Ordinal); var totaisPorCliente = totais.GetAlternateLookup<ReadOnlySpan<char>>(); foreach (var linha in linhas) { // Formato: PEDIDO;CLIENTE;SKU;QUANTIDADE;PRECO ReadOnlySpan<char> resto = linha; ProximoCampo(ref resto); // número do pedido (não usado no relatório) var cliente = ProximoCampo(ref resto); ProximoCampo(ref resto); // SKU (não usado no relatório) var quantidade = int.Parse(ProximoCampo(ref resto), NumberStyles.Integer, CultureInfo.InvariantCulture); var preco = decimal.Parse(resto, NumberStyles.Number, CultureInfo.InvariantCulture); if (bloqueados.Contains(cliente)) continue; // Busca pelo span: a string do cliente só é criada na primeira vez que ele aparece ref var total = ref CollectionsMarshal.GetValueRefOrAddDefault(totaisPorCliente, cliente, out _); total += quantidade * preco; } return totais .Select(t => new ItemRelatorio(t.Key, t.Value)) .OrderByDescending(r => r.Total) .ThenBy(r => r.Cliente, StringComparer.Ordinal) .Take(10) .ToList(); } private static ReadOnlySpan<char> ProximoCampo(ref ReadOnlySpan<char> resto) { var fim = resto.IndexOf(';'); var campo = resto[..fim]; resto = resto[(fim + 1)..]; return campo; } 

O CollectionsMarshal.GetValueRefOrAddDefault devolve uma referência direta para o valor dentro do dicionário. Assim, fazemos a busca e a atualização em uma única operação, em vez de buscar, somar e gravar de novo.

Repare também no que não mudou: o LINQ no final continua lá. Ele roda sobre 1.000 itens, não sobre 100 mil. LINQ não é o vilão. Algoritmo ruim é.

Passo 4: provar

Primeiro, garantir que nada quebrou. Antes de rodar o benchmark, o Program.cs compara o relatório de todas as versões com o original e interrompe a execução se houver qualquer diferença:

var esperado = RelatorioOriginal.Gerar(linhas, bloqueados); var bloqueadosSet = new HashSet<string>(bloqueados, StringComparer.Ordinal); var versoes = new[] { RelatorioEtapas.Etapa1UmaPassada(linhas, bloqueados), RelatorioEtapas.Etapa2HashSet(linhas, bloqueadosSet), RelatorioOtimizado.Gerar(linhas, bloqueadosSet) }; if (versoes.Any(v => !esperado.SequenceEqual(v))) throw new InvalidOperationException("As versões produziram relatórios diferentes. A otimização mudou o comportamento."); 

Depois, os números. Medições com 100 mil linhas e 1.000 clientes, no .NET 10:

Agora dá para enxergar o que cada mudança entregou:

• A Etapa 1 foi responsável por quase todo o ganho de tempo (de 1,5 s para 40 ms). Uma mudança de algoritmo, sem nenhuma técnica avançada.
• A Etapa 2 reduziu mais um terço do tempo com uma única linha alterada.
• A Etapa 3 praticamente zerou as alocações: de 25 MB para 0,23 MB. Em um método chamado milhares de vezes por minuto, isso significa muito menos trabalho para o Garbage Collector.

Os valores absolutos vão mudar na sua máquina. As proporções, não. O repositório tem o BenchmarkDotNet configurado para você reproduzir.

Onde a IA mais erra em performance

Usando IA todos os dias, esses são os erros que mais vejo nas sugestões:

• Otimizar o que não é gargalo. Trocar o LINQ final por um for não muda nada quando ele roda sobre 1.000 itens.
• Micro-otimização antes do algoritmo. Span e stackalloc não salvam um código O(n²). Primeiro o algoritmo, depois as alocações.
• Mudar comportamento sem perceber. Remover o CultureInfo.InvariantCulture "para simplificar" quebra o parsing de 19.90 em um servidor configurado em português.
• Paralelizar por reflexo. Parallel.ForEach em um laço que já leva 12 ms costuma piorar o resultado e ainda introduz problemas de concorrência.

Conclusão

A IA acelera muito o trabalho de performance: encontra hipóteses em segundos, explica complexidade e escreve a primeira versão do código otimizado. Mas ela não substitui o método.

Meça antes, peça com critério, mude uma coisa por vez e prove com números. É assim que a IA deixa de ser um gerador de palpites e vira uma ferramenta de engenharia.

O código completo, com o benchmark, a validação e o CLAUDE.md, está no meu GitHub: github.com/hgmauri/sample-performance-ia

E você, já pegou a IA sugerindo uma "otimização" que piorou o código? Conta nos comentários.