Meu benchmark estava errado

Meu primeiro benchmark provava exatamente o que eu esperava. O problema é que ele estava errado.

Eu investigava uma tela crítica de um portal interno de remuneração. Ela levava 4,3 segundos para abrir, e a hipótese parecia pronta: o endpoint tinha 1.088 linhas, 147 pontos de query e 53 laços. Era tentador começar pela refatoração.

Antes disso, montei um harness que subia a aplicação real e contava as queries executadas. Na primeira versão, instalei o listener dentro do laço. O contador passou de 354 para 708 e depois para 1.062 conforme eu repetia o caso — enquanto o tempo de parede permanecia estável.

O instrumento estava multiplicando a contagem. Corrigi o benchmark antes de usar qualquer número para defender uma mudança.

A medição válida derrubou também a hipótese inicial. O problema principal não era quantas queries existiam, mas quanto cada uma custava: 10 de 11 tabelas de integração, somando 293 mil linhas, não tinham índice. Uma única forma de consulta consumia 69% do tempo de banco.

Derivei sete índices dos predicados que o endpoint realmente usava. No pior caso medido, a tela caiu de 4.271 ms para 354 ms — 12,1 vezes mais rápida. A query mais quente foi de 2.949 ms para 19,2 ms.

O controle importava tanto quanto o ganho: a resposta continuou byte-idêntica, com 40.737 bytes, em quatro fechamentos diferentes. E o benchmark ainda deixou a próxima camada explícita: 316 das 354 queries eram lookups repetidos em laço.

Eu quase refatorei o lugar mais visível do problema. Medir primeiro mostrou o lugar mais caro — e, antes disso, mostrou que a minha própria régua estava errada.

Quando uma tela está lenta, qual evidência você coleta antes de começar a refatorar?