Adicionar Hardware Não Compensa Software Lento

Relação de Amor e Ódio
Foto: Jay Murdock

Adicionar Hardware Não Compensa Software Lento
29/10/2009

Por causa da redução do preço do hardware ou limitações de desenvolvimento (tempo, experiência, etc), tornou-se prática comum colocar mais máquinas para compensar o fraco desempenho dos sistemas.

Além de maior consumo de energia e dos impactos ambientais, isto não significa tanta melhoria assim nos resultados.

"Você é programador? Quer fazer algo pelo meio ambiente e mesmo, fazer do mundo um lugar melhor? Então comece a otimizar seu código! - Jeff Atwood."

Simplesmente colocar mais equipamento tem sido a solução preferida ao invés de fazer o software rodar mais rápido com o hardware existente. Fazer mais com menos é uma regra importante a ser lembrada, tanto quanto a Lei de Wirth: "Software fica lento mais rápido do que o hardware acelera."

Como resultado, isto anula os ganhos com a Lei de Moore!!! O hardware fica mais rápido a cada 18 meses, mas o software dobra de tamanho, fica maior, mais lento.

Jeff Atwood sugere alguns passos para começar:

1. Coloque hardware mais rápido e barato para o problema de performance.
2. Se o aplicativo atingir sua meta de performance, pare por aí mesmo.
3. Faça benchmarks para determinar aonde estão os problemas de performance do seu software.
4. Analise e otimize as áreas que você identificou no passo anterior.
5. Se agora o aplicativo atingir sua meta de performance, pare por aí mesmo.
6. Volte ao passo 1.

Outra coisa importante a observar é quais aspectos otimizar, como por exemplo, a interação com o usuário. Um tempo de resposta de até um segundo é até aceitável. A partir de um segundo, isto já chama a atenção do usuário e pode começar a irritar. Se passar de dez segundos (máximo!), o usuário vai perder a linha de raciocínio e passar a fazer outras coisas enquanto espera.

Para grandes volumes de dados também existirão os aspectos de tempo de execução e da quantidade de volumes alocados durante o processamento, que certamente afeta outras tarefas que poderão estar sendo feitas.

Otimização de performance envolve mais testes e menos adivinhação. Quando se pensa numa escala de milhões de operações por segundo, qualquer detalhe pode ser importante. Mas também existem detalhes que tomam tempo e não valem a pena otimizar.

Com certeza, a otimização requer conhecimento efetivo e prática dos recursos e técnicas adotadas.

Pessoal com menos experiência vai ter melhores resultados se trabalhar em grupo e utilizarem intensos benchmarks para analisar cada porção do software.

E claro, isto vale para mim e para todos: Sempre estude. Procure aprender de quem sabe mais que você. Graças a internet, hoje alguns dos melhores programadores do planeta mantém sites, blogs, etc com um amplo conjunto de informações e código fonte que merecem ser cuidadosamente estudados.

Dica: soluções de estruturas de lógica, de "como fazer", podem ser feitas com diferentes linguagens, portanto, amplie seu foco de estudos. Como se diz faz décadas, basicamente "quase tudo são IFs e assinalamentos."

As vezes, descobre-se que seria mais desejável reescrever o software. Isto deve ser considerado quando:

1. O código for efetivamente ruim ou mau feito;
2. A solução atual puder ser realmente melhorada;
3. Houver incompatibilidade na maneira que o código faz o processamento, em relação a algum outro recursos, normalmente externo.

E lembrando, muitas vezes o código é reescrito apenas porque o programador não entendeu o que foi feito. Geralmente falta estudar o código. Portanto, antes de qualquer coisa, estude o código e a solução de lógica adotada, conheça a ferramenta ou linguagem que está usando.

Soluções de automatização de performance, como as existentes nos gerenciadores de banco de dados e, em certas linguagens de programação, podem muitas vezes ser uma armadilha. As pessoas acham que o computador vai resolver sózinho o trabalho de melhorar a execução do código, mas esquecem completamente que isto vai ser feito de acordo com algumas regras padronizadas. Logo, com frequencia os resultados podem ser bem fracos em relação ao esperado.




Leia também:

• Não é Máquina Atolada. A Performance É Que Foi Prô Brejo...
• Performance: Quando A Culpa Não é do Banco de Dados
• 
  Como ser um bom programador

.'.