Você já otimizou o lugar errado porque "achava" que era ali? Intuição é um método caro. Profiling é o antídoto.
No post eu cubro a abordagem que funciona na prática:
🔍 cProfile — identifica onde o tempo está sendo gasto, linha a linha de chamada de função. Está na stdlib, não precisa instalar nada, e é suficiente pra 90% dos casos.
📊 pstats — filtra e interpreta os resultados. Ideal pra integrar em scripts de CI e comparar versões.
💾 memory_profiler — quando o problema não é tempo, é RAM. Mostra incremento de memória linha a linha. Aquele f.readlines() inocente que aloca 264 MB? Ele aparece.
A metodologia é simples: reproduza o problema de forma isolada → meça → encontre o culpado nos dados → corrija → meça de novo.
Sem dados, você otimiza o que parece lento. Com profiling, você sabe.
👉 https://www.riverfount.dev.br/posts/profiling-em-python/
#Python #SoftwareEngineering #Performance #Profiling #BackendDev
Profiling em Python: Encontrando Gargalos com cProfile e memory_profiler
Existe um padrão que se repete em quase todo projeto Python que cresce. O código funciona, os testes passam, a feature está pronta — aí alguém percebe que uma rota específica demora três segundos quando deveria demorar duzentos milissegundos. Ou que um processo que roda em batch está consumindo 4 GB de RAM sem nenhuma razão óbvia. O instinto natural é abrir o código e começar a suspeitar. Aquele loop ali, essa chamada de banco, aquela list comprehension aninhada. O problema é que intuição é um método caro: você otimiza o que acha que é lento, gasta horas em algo que mal contribui para o tempo total, e o gargalo real continua intacto.








