Onde estão os maiores ganhos de desempenho?

Na escolha do algoritmo e da estrutura de dados, que muda a forma de crescimento (o Big-O). Trocar busca linear por dicionário, ou a bolha por uma ordenação rápida, economiza ordens de grandeza com dados grandes. Microajustes numa linha, dentro da mesma forma, rendem muito pouco em comparação.

O que é otimização prematura?

É gastar esforço deixando o código mais rápido antes de saber se aquilo é lento e importa, muitas vezes sacrificando a clareza. É considerada uma armadilha porque desperdiça tempo e suja o código. A recomendação é escrever claro primeiro e otimizar só o que comprovadamente é lento.

Então eficiência não importa em programas pequenos?

Com poucos dados, a diferença entre algoritmos some, porque tudo é instantâneo. Ali, prefira a clareza. A eficiência importa quando os dados são grandes ou o trecho roda muitas vezes. O truque é escolher algoritmos e estruturas adequados ao tamanho esperado, sem obsessão com microssegundos onde não faz diferença.

É o trecho do programa que concentra o custo e limita o desempenho, como o ponto estreito de uma garrafa. Num programa lento, geralmente uma pequena parte é responsável pela maior parte do tempo. Otimizar essa parte traz ganho real; otimizar o resto, que roda pouco, é esforço desperdiçado.

Como sei qual trecho otimizar?

Medindo. Existem ferramentas que mostram onde o programa gasta tempo, revelando o gargalo. A regra é não adivinhar: programadores costumam errar o palpite sobre o que é lento. Meça, ache o gargalo, otimize só ele, e meça de novo para confirmar o ganho. Otimizar no escuro é desperdício.

Comprar um computador melhor resolve a lentidão?

Ajuda um pouco, mas não conserta um algoritmo de forma ruim com dados grandes. Um algoritmo quadrático sobre milhões de itens vai travar mesmo numa máquina potente, porque o problema é a forma de crescimento, não a velocidade do hardware. Trocar o algoritmo rende muito mais que trocar a máquina.

Módulo 12 - Quanto custa: eficiência e a noção de Big-O

Escolher e otimizar com bom senso

8 min de leitura · por Cesar Gargiulo, revisado pela equipe ValorFinal e GuardiaSec · Atualizado em 08/07/2026

O que você vai aprender

Saber que os maiores ganhos vêm da escolha de algoritmo e estrutura.
Entender por que otimizar cedo demais é uma armadilha.
Reconhecer quando o custo não faz diferença (dados pequenos).
Aplicar o bom senso: primeiro clareza, depois eficiência onde importa.

Onde moram os grandes ganhos

Depois de aprender a medir custo, surge a tentação de otimizar tudo, apertando cada linha para economizar operações. Isso é quase sempre um erro, e entender por quê é o que separa o uso sábio da eficiência do uso obsessivo. Os grandes ganhos de desempenho quase nunca vêm de microajustes numa linha; vêm de mudar a forma de crescimento, ou seja, de trocar o algoritmo ou a estrutura de dados. Trocar uma busca linear O(n) por uma consulta de dicionário O(1) não economiza uns por cento, economiza uma ordem de grandeza inteira quando os dados são grandes. Trocar a ordenação da bolha O(n ao quadrado) por uma ordenação rápida O(n log n) transforma horas em segundos. É subindo na hierarquia do Big-O que você ganha de verdade; espremer operações dentro da mesma forma de crescimento raramente vale o esforço.

Uma balança comparando dois tipos de otimização. De um lado, pesado, uma placa trocar de algoritmo ou estrutura, com uma seta de O(n ao quadrado) para O(n log n) e um ganho enorme destacado. Do outro lado, leve, uma placa apertar linhas dentro da mesma forma, com um ganho minúsculo. — O ganho grande está em mudar a forma de crescimento (algoritmo, estrutura), não em microajustes na mesma forma.

A armadilha de otimizar cedo

Existe um conselho famoso na programação: otimizar cedo demais é a raiz de muitos males. A ideia é que gastar esforço deixando um código mais rápido antes de saber se ele é lento costuma desperdiçar tempo e, pior, sujar o código. Otimizações frequentemente trocam clareza por velocidade, e um código torto e difícil de entender em nome de um ganho que ninguém pediu é um péssimo negócio. A ordem sábia é o contrário: primeiro escreva um código correto e legível, do jeito mais claro que você conseguir. Depois, se e somente se ele estiver lento de verdade, meça para descobrir onde está o gargalo, o trecho que concentra o custo, e otimize só aquele ponto. Na maioria dos programas, a maior parte do código não precisa ser rápida, porque roda poucas vezes ou sobre poucos dados. Focar o esforço no gargalo é o que rende; otimizar no escuro é desperdício.

🎮 Jogo da aula

Bom senso de eficiência

Decida se cada afirmação sobre otimização e eficiência é verdadeira ou falsa.

O equilíbrio: clareza primeiro, eficiência onde importa

O bom senso da eficiência se resume a um equilíbrio. De um lado, você não pode ignorar a eficiência: usar um algoritmo quadrático sobre milhões de itens trava o programa, e isso é um erro de projeto que nenhum computador rápido conserta. De outro, você não deve virar refém dela: perseguir microssegundos em código que roda pouco, ou sacrificar a clareza por velocidade desnecessária, é desperdício. O caminho do meio é este: conheça as formas de crescimento e escolha, desde o início, algoritmos e estruturas adequados ao tamanho dos seus dados, isso é decisão de projeto, não otimização prematura. Escreva o resto do código de forma clara e correta. E, se o programa estiver lento, meça para achar o gargalo e otimize só ali. Com esse critério, você aproveita tudo o que aprendeu neste módulo sem cair nos dois extremos, o do descuido e o da obsessão. É assim que o programador experiente pensa em desempenho, e agora você também.

Teste rápido

Seu programa está lento processando milhões de registros. Onde procurar o maior ganho de desempenho?

Perguntas frequentes

Onde estão os maiores ganhos de desempenho?: Na escolha do algoritmo e da estrutura de dados, que muda a forma de crescimento (o Big-O). Trocar busca linear por dicionário, ou a bolha por uma ordenação rápida, economiza ordens de grandeza com dados grandes. Microajustes numa linha, dentro da mesma forma, rendem muito pouco em comparação.
O que é otimização prematura?: É gastar esforço deixando o código mais rápido antes de saber se aquilo é lento e importa, muitas vezes sacrificando a clareza. É considerada uma armadilha porque desperdiça tempo e suja o código. A recomendação é escrever claro primeiro e otimizar só o que comprovadamente é lento.
Então eficiência não importa em programas pequenos?: Com poucos dados, a diferença entre algoritmos some, porque tudo é instantâneo. Ali, prefira a clareza. A eficiência importa quando os dados são grandes ou o trecho roda muitas vezes. O truque é escolher algoritmos e estruturas adequados ao tamanho esperado, sem obsessão com microssegundos onde não faz diferença.
O que é um gargalo?: É o trecho do programa que concentra o custo e limita o desempenho, como o ponto estreito de uma garrafa. Num programa lento, geralmente uma pequena parte é responsável pela maior parte do tempo. Otimizar essa parte traz ganho real; otimizar o resto, que roda pouco, é esforço desperdiçado.
Como sei qual trecho otimizar?: Medindo. Existem ferramentas que mostram onde o programa gasta tempo, revelando o gargalo. A regra é não adivinhar: programadores costumam errar o palpite sobre o que é lento. Meça, ache o gargalo, otimize só ele, e meça de novo para confirmar o ganho. Otimizar no escuro é desperdício.
Comprar um computador melhor resolve a lentidão?: Ajuda um pouco, mas não conserta um algoritmo de forma ruim com dados grandes. Um algoritmo quadrático sobre milhões de itens vai travar mesmo numa máquina potente, porque o problema é a forma de crescimento, não a velocidade do hardware. Trocar o algoritmo rende muito mais que trocar a máquina.

Fontes

Seu progresso fica salvo neste aparelho. Assinantes sincronizam entre os aparelhos.

← A notação Big-O: o vocabulário do custo Concluir e avançar →