Rodrigo Kumpera Weblog

Performance nunca foi um assunto fácil. Medir é complicado, comparar resultados é quase irrelevante, comparar linguagens é inútil. Porém as pessoas continuam insistindo no assunto, de um lado os que defendem linguagens gerenciadas dizendo que elas são tão rápidas quanto C ou C++; do outro lado ficam a demonstrar como isso não é possível.

Não se trata apenas do uso de micro-benchmarks, ou de otimizar melhor um alvo, ou da metodologia ser falha. Se trata apenas de falta de comprometimento. Não se pode medir performance daquilo que não se está envolvido pois o resultado é irrelevante. Qualquer tentantiva nessa direção só vai provar que a pessoa é tola.

Quando falo em compromisso me refiro ao fato de que não adianta tentar medir a performance sem estar envolvido na melhora dela. Medições devem ser feitas em softwares reais, não de fabricações de Oz. E o corolário disso é que comprar linguagens é um exercício de futilidade, pois não faz sentido manter o mesmo programa em Java e C++, por exemplo.

A performance de um programa é fator de muito mais coisas que apenas a velocidade bruta do meio de execução – seja uma VM ou código nativo. Principalmente para grandes sistemas, a complexidade arquitetural e características sistêmicas tem muito maior influencia. Já vi isso acontecer demais para ignorar.

Isso significa que micro-benchmarks são irrelevantes e pura obra do ego de seus criadores? Não, pelo contrário, diz apenas que quase sempre as pessoas envolvidas não estão comprometidas com os resultados. Um exemplo prático, medir a performance com ponto flutuante do gcc só é útil aos seus desenvolvedores, pois somente estes tem o compromisso em melhorá-la, para os demais é uma enorme perda de tempo.

Toda discussão de “Minha linguagem é mais rápida que a sua” parece esquecer de que para aplicações de significativa complexidade a maioria dos micro-benchmaks usados são irrelevantes. Para a maioria dos projetos, oque importa é quanto a plataforma torna fácil escrever programas que sejam rápidos. Não adianta ser super veloz se o desenvolvedor vai precisar fazer uma enorme série de sacrifícios para manter sua produtividade.

Existe uma série de exemplos bem intrigantes de como escolhas óbvias trazem resultados não óbvios em termos de performance. Desde gerenciamento de memória a execução especializada de código. Porém não espero ver as pessoas se eduquem nesse ponto, pois é uma causa fundamentalmente perdida, já que não existe razão suficiente contra um ego ferido e o fato de alguém na internet estar errada.