Medir antes de otimizar com timeit

A regra de ouro da performance

Existe uma frase antiga entre programadores: a otimização prematura é a raiz de muitos males. Ela não diz para ignorar performance, e sim para não sair mexendo no código na base do achismo. O motivo é simples: a intuição humana sobre o que é lento é péssima. Você jura que aquele laço é o vilão, gasta uma tarde reescrevendo ele, e no fim descobre que o tempo todo estava numa leitura de arquivo que você nem olhou. Por isso a regra de ouro do avançado é medir antes de otimizar. Primeiro você mede e descobre onde o tempo realmente vai; só então decide se e onde vale a pena agir.

Medir também protege você de piorar sem perceber. Sem número na mão, é fácil trocar um código claro por um código torto acreditando que ficou mais rápido, quando na prática nada mudou ou até piorou. Com medição, cada mudança vira uma comparação objetiva: a versão nova é mais rápida que a antiga? Em quanto? Vale a perda de legibilidade? Essa disciplina transforma otimização de adivinhação em engenharia. E a primeira ferramenta dessa disciplina, para trechos pequenos, é o timeit.

Medindo trechos com timeit

O timeit resolve um problema real de medição: um único cronômetro engana. O relógio do sistema tem baixa resolução, e o sistema operacional pode interromper seu programa no meio da conta. Por isso o timeit roda o mesmo trecho milhares de vezes e reporta o melhor tempo, que é o mais próximo do custo puro do código. No código, você passa a instrução a medir como texto, e um setup separado com o que precisa existir antes, mas que não deve entrar na conta.

import timeit

# Compara juntar strings com + versus str.join numa lista
soma = """
s = ""
for n in range(1000):
    s += str(n)
"""

join = """
s = "".join(str(n) for n in range(1000))
"""

t_soma = timeit.timeit(soma, number=1000)
t_join = timeit.timeit(join, number=1000)
print(f"soma com +: {t_soma:.3f}s")
print(f"str.join:   {t_join:.3f}s")

timeit roda cada trecho 1000 vezes; str.join costuma vencer a concatenação com +.

Repare no cuidado com o que entra na medição. Quando você tem uma preparação que não faz parte do que quer medir, como criar uma lista grande, coloque isso no parâmetro setup, e não junto da instrução. Se o setup entrar na conta, o tempo medido reflete a preparação, não o trecho de interesse, e a comparação fica sem sentido. Esse é o erro mais comum de quem começa a medir: cronometrar o preparo do experimento junto com o experimento.

O que o microbenchmark não conta

O timeit é ótimo para trechos pequenos e isolados, mas não conte com ele para entender um programa inteiro. Medir uma linha fora de contexto pode levar a conclusões falsas: um trecho que parece lento sozinho pode ser irrelevante no todo, porque roda uma vez só, enquanto um trecho aparentemente barato pode ser o vilão por rodar um milhão de vezes. O microbenchmark responde qual das duas versões deste trecho é mais rápida, não onde meu programa gasta tempo. Para essa segunda pergunta, que costuma ser a que importa, existe o profiler, tema da próxima aula.

import timeit

# Medir uma função definida no proprio arquivo:
# passe o setup para importar do escopo global.
def eh_primo(n):
    if n < 2:
        return False
    for d in range(2, int(n ** 0.5) + 1):
        if n % d == 0:
            return False
    return True

t = timeit.timeit("eh_primo(9973)", setup="from __main__ import eh_primo", number=10000)
print(f"eh_primo(9973): {t:.4f}s em 10000 chamadas")

Para medir uma função sua, importe-a no setup com from __main__ import.

Guarde a hierarquia mental: primeiro você descobre o gargalo no programa todo, com um profiler; depois, se quiser afinar uma parte específica, usa o timeit para comparar alternativas daquele trecho. Inverter a ordem é o que leva à otimização prematura. Medir a linha errada com precisão de nanossegundo não adianta nada se ela não é o gargalo. A precisão do timeit só rende quando aplicada no lugar que o profiler apontou.