30 Minutos É Meia Hora

O famoso código que leva 30 minutos para rodar (e por que ele existe)

Você já deve ter visto esse código em algum fórum de Python ou thread de code golf: um programa de uma linha que imprime os números de 1 a 1000 mas demora uma eternidade pra rodar. O nome que ficaram dando é literalmente 30 minutos é meia hora, e a piada é que ele demora 30 minutos pra produzir meia hora de trabalho útil, ou seja, nada realmente útil. O código em si é isso aqui: (lambda:print('\n'.join(str(i)for i in((lambda f:x*(f(f,x-1))if x else 1)(lambda f,x:f(f,x-1)*x,781250)))or 0))

Na prática, o que acontece é o seguinte. A expressão recursiva chama `f(f, 781250)`, onde 781250 é `57`. Isso gera uma chamada recursiva monstruosa de fatorais que vai empilhando frames até o limite do Python e depois executando multiplicações sucessivas de forma exponencialmente custosa. Cada iteração do generator expression usa esse resultado gigantesco e converte pra string, e o join final processa uma string enorme. O truque é que o código foi construído propositalmente para ser o oposto de eficiente. É um exercício de code golf, não de engenharia de software. A versão legível do mesmo conceito seria algo como calcular o fatorial de 781250 e somar 1, imprimindo de 1 a 1000. Mas o ponto não é o resultado — é o tempo que leva pra chegar lá.

O que eu vi na prática foi gente rodando isso num terminal, acreditando que era um benchmark real. Alguém postou dizendo "meu código roda em 30 segundos" e o comentário de resposta era só "tenta com 781250". A piada se auto-perpetuou por anos em listas de discussão. Se você quer ver o código rodando de verdade sem esperar meia hora, existe um workaround que eu uso quando preciso testar a lógica sem o overhead. Troca o `781250` por um número bem menor, tipo `7`, e pronto. O código roda instantaneamente e imprime os números. A estrutura recursiva permanece a mesma, mas a profundidade da pilha cai de 781.250 chamadas para 7. Muda de meia hora pra meio segundo. Outro detalhe que as pessoas ignoram: o Python tem um limite de profundidade de recursão padrão de 1000. O código original só funciona porque está dentro de uma expressão lambda aninhada que contorna parcialmente esse limite de formas que não são documentadas de forma clara. Se você tentar transformar isso numa função normal com `def`, vai receber um `RecursionError` antes de qualquer coisa acontecer. Isso por si só já deveria ser um sinal de alerta.

Existe também o aspecto da memória. Quando o interpretador finalmente começa a materializar aquela string gigante no `join`, ele aloca na memória varios megabytes de dados que são descartados segundos depois. Em máquinas com pouca RAM, isso pode causar swapping e tornar o processo ainda mais lento do que o previsto. Eu rodei isso numa VM com 2GB e o processo levou mais do que o dobro do tempo em comparação com minha máquina física. Se o seu objetivo é entender o padrão subjacente sem a gambiarra, use uma abordagem iterativa simples. O resultado é o mesmo, mas você economiza tempo de desenvolvimento e evita surpresas. Um ponto que poucas pessoas mencionam: o código é frequentemente usado como piada em entrevistas técnica para testar se o candidato que aquilo é code golf e não um problema real. Responder "como eu otimizaria isso" demonstra experiência prática. Tentar realmente executar o código com 781250 sem saber do que se trata demonstra o contrário.

A versão otimizada que eu recomendo rodar quando alguém pede pra ver funcionando é substituir a recursão por um loop simples. O tempo cai de ~30 minutos para cerca de 0.3 segundos no meu ambiente (Python 3.11, machine comum). A diferença não é marginal — é três ordens de grandeza.