Já vi acontecer inúmeras vezes: o sistema é escrito, testado, e funciona bem. É instalado em produção e funciona por uma semana ou duas. Então começa a ficar extremamente lento, a ponto de não ser mais usável. A sequência é também muito comum: o programador vai “otimizando” o código no escuro, usando a intuição, e perde muito tempo fazendo pequenas melhorias.
A solução para a primeira parte do problema é simples, mas geralmente ignorada: sempre teste utilizando um volume considerável de dados. É simples testar com dois ou três registros que você mesmo cadastrou, mas é importantíssimo garantir que a performance continue adequada com um volume de dados real. Utilize uma cópia de dados de produção caso existam e estejam disponíveis, ou utilize um gerador de dados (como o exemplo que acompanha o DBX4) para popular uma quantidade de registros compatível com o que volume esperado para produção.
O segundo problema é mais interessante. A intuição geralmente está errada – o que torna o código lento pode ser o que você menos espera.
Gargalos
Geralmente a lentidão é causada por gargalos no código, trecho de uma ou duas linhas que levam uma grande porcentagem do tempo total de processamento. Muitas vezes é fácil de encontrar uma alternativa para evitar essa demora, como reordenar o código para tratar a condição mais comum primeiro. Ao resolver um gargalo geralmente outro toma seu lugar, passando a ser responsável pela maioria da demora restante. A partir daí, resolver gargalos é uma questão de um retorno decrescente: cada otimização vai diminuir cada vez menos o retorno obtido.
Como um exemplo, vamos imaginar um hipotético processamento de registros que leve 10 segundos. Utilizando ferramentas apropriadas, descobrimos que a abertura da query para trazer os registros leva 80% do tempo. Analisando esta consulta, descobrimos uma forma de alterá-la para abrir praticamente instantaneamente. Agora o processamento leva cerca de 2 segundos. Se conseguirmos encontrar um novo gargalo que leve 80% do novo tempo e uma forma de removê-lo, ganhamos mais 1.6 segundos. Se repetirmos o processo mais uma vez, não conseguiremos melhorar mais que meio segundo. Se a qualquer momento trabalharmos em em outro trecho do código que não ser um desses três gargalos, estaremos perdendo nosso tempo e não teremos melhorias maiores que alguns milisegundos. É necessário bom senso para determinar a hora de parar.
Se não existe um gargalo claro, e a performance em geral ainda não é adequada, provavelmente é hora de procurar um algoritmo completamente diferente para resolver o problema.
Na prática nem sempre é possível remover gargalos completamente. Mesmo assim, deve se ter em mente que otimizar o restante do código muitas vezes não trará resultados perceptíveis.
No exemplo acima, escrevi que descobrimos o tempo levado por cada trecho do código utilizando “ferramentas apropriadas”. O que seria isso?
Profilers
Profilers são ferramentas que permitem determinar o tempo gasto na execução do seu código. Existem várias formas de fazer essa medição, desde uma forma arcaica manual, salvando o horário atual em um arquivo de log por exemplo, ou bem elaborada utilizando uma ferramenta profissional como o AQTime. Utilizar uma ferramenta profissional é ótimo, é claro, mas é cara e algumas vezes até um exagero para um problema mais simples.
Existem duas categorias de profilers: Sampling Profilers e Intrumenting Profilers. A primeira faz medições (samples) regulares em pontos aleatórios (a cada milisegundo, por exemplo). Essa forma não afeta a execução do código, mas pode ser pouco precisa. Um Intrumenting Profiler adiciona código para efetuar medições em lugares exatos dentro do seu programa. Essa categoria se subdivide em profilers que instrumentam seu código fonte inserindo essas verificações, e profilers que alteram o código de máquina conforme ele é executado para inseri-las. Uma maior precisão é conseguida desta forma, mas sob o custo de alterar sutilmente o fluxo do seu código. Como na mecânica quântica, o ato de medir pode pode estar alterando o resultado. Na prática, nenhum dos dois é extremamente superior: deve-se pesar os prós e contras, e quem sabe até utilizar os dois tipos como uma boa alternativa para encontrar diferentes tipos de gargalos.
A forma mais simples de determinar o tempo levado por um método é utilizar uma forma simples e manual de um source intrumenting profiler – escrever código para salvar o tempo inicial e final, e exibir/armazenar esse valor. A glanularidade é exatamente qual quiser, até cada linha. A precisão depende da forma que o tempo for medido – não recomendo a função Now, pois não é muito precisa. GetTickCount é adequada para a maioria dos casos, tendo precisão de 1ms. Pode ser usada mais ou menos assim:
var
t: Cardinal;
begin
t := GetTickCount;
EfetuaProcessamento;
WriteLn(GetTickCount - t);
end;
Se uma precisão maior que 1ms for necessária, recomendaria a API QueryPerformanceCounter. A precisão dela depende do processador, e é necessário chamar QueryPerformanceFrequency para determiná-la. Outra alternativa é o opcode RDTSC, mnemônico para read time stamp counter, que também retorna o número de ticks desde que o processador foi reiniciado, assim como GetTickCount, mas com maior resolução. Essa alternativa não é recomendada hoje em dia por potenciais problemas relacionados a processadores multicore e processadores com clock variável (geralmente em portáteis).
Essa forma manual de profiling é claramente adequada apenas para pequenos problemas e testes rápidos. Para casos mais elaborados, deve-se considerar utilizar algum dos profilers disponíveis:
ProDelphi é um source instrumenting profiler, portanto ele faz (e desfaz) alterações no seu código fonte. Possui uma versão gratuita, com limitações, e uma versão comercial por 47.50 €.
GpProfile é outro source intrumenting profiler. Gratuito, open source, mas sem atualizações por muitos anos.
Sampling Profiler é, como o nome diz, um sampling profiler, Freeware, mas sem código fonte. Uma boa alternativa pra quem não quer gastar com ferramentas comerciais e não quer alterações no seu código fonte.
AQTime é, sem dúvida, a ferramenta mais avançada e completa. É um instrumenting profiler que só altera o código de máquina ao ser executado, então não requer nenhuma alteração no código fonte. Além de tempo gasto em procedimentos e linha por linha, possui modos onde verifica uso de memória, de recursos, e diversas outras análises extremamente interessantes. Custa $599.
Na terceira parte desta série pretendo apresentar um exemplo prático de otimização de um projeto usando um profiler.
