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.

Comments

• Anonymous
  July 21, 2008
  Concordo 100% com voce, e sempre que possível adoto esta política nos sistemas que trabalho mas tem um porém, dependendo da criticidade do sistema para a companhia, o nível de ansiedade em relação a ele e o prazo, é complicado conseguir o tempo necessário para os ajustes (tunning) dos componentes que realmente importam. Em sistemas distribuídos e/ou "em camadas", testes de carga em cada um dos componentes costumam dar bons resultados de forma a antecipar gargalos e assim evitar a situação acima descrita.

• Anonymous
  July 24, 2008
  Também concordo que performance custa caro. Sempre procuro visualizar o cenário da aplicação, se realmente o negócio que ela representa necessita ser "performático", pois isso causa impacto direto, não só no seu modelo de desenvolvimento, mas também no bolso do cliente.

• Anonymous
  July 25, 2008
  The comment has been removed