Desempenho com Economia

Projetar para desempenho custa caro e é bom economizar energia – gaste apenas quando precisar.

Tenho um caso de sucesso para contar. Em 84, no meu segundo emprego (acreditem, só fiquei 4 meses no meu primeiro emprego - não agüentei o marasmo e pedi demissão), fui designado para implementar o protocolo X.25. Aceitei a tarefa e exigi que fosse implementado em C.

Bem, naquele tempo esta empresa desenvolvia em linguagem de montagem (assembly) e o pessoal achou que ia ter baixíssimo desempenho. Como já tinha desenvolvido um protótipo na universidade, sabia que um X.25 seria grande e, com isto, convenci que em C seria menos custoso.

Grupo montado (éramos 3) implementamos o nível 3 do protocolo e fomos testá-lo. Resultado? No máximo 200bps quando precisávamos de 19200bps!

Lembro-me até hoje de quanto tive que ouvir por causa daquele mau desempenho...

Seguro do que estava fazendo, pedi mais um tempo para fazer otimizações. Colocamos um analisador (profiller) para analisar o comportamento do código e constatamos que 90% do tempo o código estava tratando da interrupção para transmissão e recepção de bytes do hardware. Com isto, focamos apenas neste código reimplementando-o em assembly a partir do código original em C.

Quatro dias de otimizações e fomos para o laboratório testar. Resultado? 21000bps!

Hoje, vejo arquitetos muito preocupados com o desempenho de suas aplicações implementando over-enginnering antes da hora. Isto costuma levar a sistemas complexos, de alto custo para fazer e manter.

Meu conselho: realize provas de conceito testando primeiro as arquiteturas mais simples e pare quando o sistema mostrar que consegue, na média, um desempenho aceitável. Daí em diante gaste tempo e dinheiro apenas com as funções mais críticas. Seu bolso e suas noites vão agradecer.