Otimização de performance é uma preocupação comum para quem está começando em programação, e muitas vezes mesmo programadores experientes tem dúvidas sobre esse assunto, o que é normal uma vez que o assunto é mesmo complexo. Não vou explicar nesse post tudo o que você precisa saber sobre performance, mas pretendo dizer o mais importante: quando você precisa se preocupar. Isso mesmo, porque um erro muito comum é ver os programadores se preocupar demais com performance, na hora errada.
Então vamos lá: nossos computadores são muito potentes hoje em dia. Muito. Dificilmente mudar a lógica de um cálculo, criar uma variável a menos, otimizar um loop, ou até concatenar menos strings vai fazer algum diferença sensível. Então, não pré-otimize, não otimize antes de medir.
Vamos mostrar um exemplo. Fiz em Python só porque eu gosto, mas a mesma coisa vale para sua linguagem favorita. Escrevi os dois arquivos a seguir:
strings1.py
tamanho=20
a='a'
for i in range(tamanho):
a*=2
print(len(a))
strings2.py
tamanho=20 a='a' * (2**tamanho) print(len(a))
São duas maneiras bem diferentes de se criar uma grande string. A segunda é muito mais eficiente que a primeira. Bom, veja os resultados da execução aqui na minha máquina:
$ time python strings1.py 1048576 real 0m0.023s user 0m0.013s sys 0m0.008s $ time python strings2.py 1048576 real 0m0.021s user 0m0.012s sys 0m0.008s
Nenhuma diferença prática, certo? Aumentei a variável tamanho para 30, agora notamos diferença:
$ time python strings1.py 1073741824 real 0m1.375s user 0m0.671s sys 0m0.691s $ time python strings2.py 1073741824 real 0m0.586s user 0m0.235s sys 0m0.344s
Agora a diferença é absurda, certo? Mas quando foi a última vez que você precisou concatenar strings de um bilhão de caracteres? O caso é: se suas strings vão chegar a esse tamanho, você provavelmente vai saber disso antes. Por exemplo, se você está fazendo um software de tratamento de imagens, parece óbvio que processamento pode ser um problema, certo? Se não, gastar seu tempo e esforço com otimização de performance provavelmente não vale a pena.
Aviso: o código do exemplo 1 é muito ruim, além de dar mais trabalho para escrever. Eu não estou sugerindo que você escreva código ruim de propósito, tá? Apenas que você não se preocupe demais com performance e não gaste seu tempo resolvendo problemas imaginários.
Há, porém, algumas situações em que tudo o que eu disse acima não vale. Nossos processadores são muito rápidos, nossas memórias também. Discos já não são tão rápidos assim. Bancos de dados, mais ou menos. A internet, bom, quem pode confiar na internet, né?
Então, se você vai consumir um webservice, e pode mudar seu algoritmo para fazer dez chamados ao invés de vinte, faça isso. Se vai escrever muito no disco, e puder reduzir em 20% as operações de escrita de arquivos, faça isso. Se escrevendo uma consulta SQL mais complexa você consegue fazer muito menos consultas ao banco de dados e usar mais índices, faça isso.
Eu faço mais ou menos assim em relação a performance:
- Vamos usar a internet? Otimize sempre.
- Vamos gravar grandes arquivos, ou fazer uso intensivo de disco? Otimize sempre.
- Cálculo científico, tratamento de imagens e outras operações de processamento massivo? Otimize sempre.
- Bancos de dados com milhões de registros e uso intenso? Otimize sempre.
- Uso comum de arquivos e bancos de dados? Cuide de não escrever nada muito ruim, e otimize se der problema.
- O resto todo? Escreva pensando em legibilidade, encapsulamento e reuso. Só otimize se tiver problemas.
Publiquei um vídeo sobre isso há um tempo, se você quiser dar uma olhada: Não pré-otimize.
