Seja cuidadoso ao otimizar o seu código

São cometidos mais pecados computacionais em nome da eficiência (sem necessariamente atingi-la) do que por qualquer outra razão — incluindo a estupidez cega. — William A. Wulf.

Se você já tem um tempinho trabalhando com programação, provavelmente sabe de uma coisa em relação a otimização: geralmente gera mais prejuízo do que benefício, especialmente se você fizer o uso dela antes da hora. Quase sempre, softwares precocemente otimizados não são corretos, ou mais rápidos e nem podem ser corrigidos com facilidade.

A arquitetura não deve ser sacrificada em benefício de desempenho, o esforço deve ser aplicado na escrita de bons programas, ao invés de programas com excelente desempenho — veja, não estou diminuindo o papel de um software com bom desempenho e nem pregando que desempenho, não seja um ponto importante mas, a sua busca incessante, quase sempre, é a receita do fracasso de um programa.

Caso um programa não seja rápido o bastante, muitos outros pontos de sua arquitetura podem ser otimizados. Um bom programa, carrega consigo o Princípio da Ocultação de Informação ou Ocultamento de Informação, que é basicamente a característica de possibilitar a alteração do design de determinado componente, sem necessariamente afetar todo o sistema, possibilitando:

• Desenvolvimento em paralelo;
• Flexibilidade a mudanças;
• Facilidade de entendimento.

Tangenciando um pouco, quanto menos acessível sua classe, assim como os membros da mesma, melhor para o seu código, um componente bem projetado esconde seus dados internos e outros detalhes de outros componentes — Encapsulamento, o uso correto dos modificadores de acesso (private, protected e public) é fundamental, o cenário ideal é que a API pública de sua classe seja desenhada minuciosamente — resultando em um ou poucos membros públicos e demais membros privados, e caso seja necessário conceder acesso a uma outra classe do mesmo pacote, que seja através de um acesso package. Sei do quão tentador é sair expondo os membros das classes para facilitar os testes mas, isso não é aconselhável, existem outras formas corretas de se testar. Resumidamente é isso mas, cabe um outro post sobre o assunto.

Voltando ao assunto principal, se você tornar um tipo público mutável, provavelmente terá de fazer várias cópias defensivas não necessárias, assim como se você usar herança ao invés de composição, pode acabar associando a sua classe para sempre a sua superclasse, o pode acabar limitando o desempenho da subclasse. Dependendo do design de sua classe, a mesma pode ter um Shallow Size, Retained Size e Deep Size 2x, 5x maior!

Você deve analisar com bastante critério as consequências de desempenho nas suas decisões sobre design de API, mas felizmente um bom design de API é consistente com um bom desempenho.

Caso você queira modificar a sua API para atingir um bom desempenho, pense bem antes de o fazer, o problema de desempenho que o levou a querer modificar a sua API pode desaparecer em uma versão posterior do seu programa, em compensação, você terá que conviver com a sua API problemática e com as dores de cabeça da sustentação para sempre caso queira modifica-la para atingir um bom desempenho precocemente.

O Java é uma excelente linguagem mas, possui um modelo de desempenho fraco, em comparação com C e C++. Há um abstraction-gap ou seja, o que nós programamos é mais diferente do que a CPU executa no Java do que no C, por exemplo, o que torna bem difícil de prever com segurança os impactos das otimizações feitas.

A forma com que o Java lida com desempenho varia bastante de versão para versão e até de processador para processador, caso esteja executando o seu programa em múltiplas plataformas, talvez seja interessante avaliar os impactos das otimizações em cada uma delas.

Recentemente lidei com códigos escritos em 2005, em uma aplicação que diariamente lidava com milhões de requisições e exigia altíssimo desempenho e baixa latência nas suas respostas, foi interessante observar que algumas melhorias de desempenho envelheceram mal, diversas VM’s, novos processadores e hardware novos surgiram, tornando muito mais difícil de prever o desempenho de um programa escrito em Java nos dias atuais, do que em 2005.

Em resumo: Não gaste tempo escrevendo programas rápidos, se esforce para escrever programas bons, pois a rapidez virá com o tempo.