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 (3)
  1. ffontes says:

    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.

  2. werhmuller says:

    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.

  3. fiorentin0 says:

    Concordo. Performance custa caro. Falando em .NET, alguns desenvolvedores evitam reflection em  situações onde a perda de performance não seria significativa. A BCL usa (DataBinding, qq lugar com C# atributos, etc), vários frameworks usam…

    Não é o uso responsável na camada de aplicação que vai trazer problemas.

    Nada quem um benchmark numa console application não comprove 🙂

    []s

Comments are closed.

Skip to main content