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.

Para entender os passos necessários para otimizar seu código de uma forma que tenha um bom resultado prático sem comprometer a qualidade do código, deve-se entender alguns conceitos importantes:

1. Quando otimizar.
2. Como reconhecer qual parte do código toma mais tempo.
3. E o que fazer para diminuir o tempo tomado por essas partes do código.

Vou elaborar o primeiro item hoje, e deixar os próximos dois para artigos futuros.

Quando Otimizar

Donald Knuth escreveu, em 1974, a já famosa e gasta frase: "Devemos esquecer das pequenas eficiências, cerca de 97% do tempo. Otimização prematura é a raiz de todo o mal". Em seguida, ele elabora que não se deve ignorar os 3% restantes, mas apenas após que eles forem identificados.

Mais que isso, diz que a experiência universal de programadores (incluindo a minha), é que após utilizar ferramentas para medir a performance do código, você percebe que o que as tentativas de adivinhar quais são esses trechos críticos geralmente são falhas. É fácil perceber que tempo gasto otimizando partes do código que não são críticas para a performance é uma perda de tempo, e acabam tendo um impacto negativo quando se considera o tempo que será levado para depurar e manter esse código, agora mais complexo por otimizações desnecessárias.

O retorno da otimização costuma seguir o Principio de Pareto, que postula que apenas 20% do código é responsável por cerca de 80% da performance. Dessa forma, mesmo que se diminua pela metade o tempo levado por um trecho específico de código, se ele só influencia em 1% no tempo total de determinado processo, você só teve 0.5% de ganho de performance. Por outro lado, ao identificar um trecho que leva 30% do tempo, qualquer melhoria de performance nele terá um retorno 30 vezes maior. Na prática, vejo porcentagens ainda maiores que essa, acentuando ainda mais a importancia de localizar corretamente os trechos que levam mais tempo, conhecidos como gargalos, ou bottlenecks, se preferir um informatiquês mais elaborado.

Isso quer dizer, que, na prática, ao escrever código, evite tomar qualquer decisão no impacto de performance que ela vai ter. Decisões como usar uma ou outra função para realizar determinada tarefa devem ser tomadas com base nos méritos de legibilidade e mantenabilidade do código, muito acima de qualquer suposta diferença de performance entre elas. Não deixe a intuição de que algum ponto será um gargalo influenciar essa decisão (lembre-se, intuições geralmente são desbancadas por medições de performance). Qualquer escolha errada nesse ponto é facilmente adequada nas fases de medição e otimização.

O que isso não quer dizer, em contrapartida, é que se deve ignorar a performance na hora de planejar a solução que vai ser implementada, antes da codificação. É importante saber o que está sendo implementado e qual a complexidade dessa solução. Deve-se estimar a quantidade de itens que o código deve ser capaz de processar, e adequar a complexidade do algoritmo e estruturas de dados escolhidas para obter uma performance apropriada a esse número. Uma das soluções na etapa de diminuir o tempo tomado por determinado gargalo é substituir o algoritmo por um mais eficiente, mas tal substituição costuma ser trabalhosa e demanda mais trabalho que um planejamento adequado tomaria.

Complexidade de Algoritmos

A complexidade de algoritmos é uma medida da escalabilidade de um algoritmo. De quanto trabalho ele precisa fazer para resolver o problema conforme o número de itens aumenta. Existe uma forma padrão de analisar e representar a complexidade de algoritmos, que é a notação Big-O (raramente traduzida para Grande-O). Para determinar a complexidade de um algoritmo, conta-se o número de operações que ele faz para cada item, onde operação pode ser comparações, trocas, leituras de disco, etc. Em seguida, é determinada uma expressão que representa essa quantidade. Uma complexidade O(n), ou linear, representa que o número de operações é constante e proporcional ao número de itens na lista. O(n²), ou quadrática, mostra a proporção que o número de operações cresce conforme o número de itens aumenta.

É muito mais fácil de entender essa representação graficamente:

A figura representa o número de operações efetuadas por dois algoritmos hipotéticos, um O(n) e o segundo O(n²). Algumas características importantes:

• É fácil de observar a falta de escalabilidade do segundo algoritmo. Conforme o número de itens aumenta, o número de operações aumenta muito rapidamente.
• Não é um gráfico de f(x) = n e g(x)=x², apesar que esse seria um exemplo igualmente válido (e mais simples). A expressão mostrada pela notação O não é exatamente o número de operações que vão ser executadas, mas sim uma representação de como esse número muda em relação à quantidade de itens processados. Não existe O(n + 10) nem O(10n). Ambos seriam representados por O(n). Dois algoritmos podem ter a mesma complexidade mas um efetuar mais operações, ou o mesmo número de operações e levar um tempo maior que o outro (se a operação for mais demorada).
• O algoritmo mais complexo pode levar menos tempo que o menos complexo. O tempo extra gasto no caso mais simples pode ser a geração de uma tabela de pesquisa, por exemplo, que pode levar mais tempo do que a busca por força em um número pequeno de itens. Supondo que no gráfico acima a operação efetuada pelos dois algoritmos seja equivalente, o mais complexo vai ser mais rápido até um pouco mais de 150 itens. Se o número de itens vai ser baixo (por exemplo, processar as janelas abertas em um editor de imagens), a segunda opção pode ser a mais adequada. Se o número for alto (ou desconhecido), deve-se tomar uma extrema atenção na complexidade do algoritmo que será usado.

Sabendo desses detalhes, fica mais fácil determinar a complexidade de um algoritmo qualquer. Um exemplo seria a busca de um item em uma lista desordenada. Em pseudocódigo:

resultado = -1
de i := 1 até Lista.Count
  se Lista[i] = Item
    resultado = i
retorne resultado

A operação que está sendo contada é a comparação. O número de operações é sempre igual ao número de itens na lista, claramente O(n). Uma otimização óbvia reduz o número de comparações:

de i := 1 até Lista.Count
  se Lista[i] = Item
    retorne i
retorne -1

Nesse novo exemplo, no melhor caso, o item procurado é o primeiro da lista, sendo feita apenas uma comparação. No pior caso, não é encontrado, sendo feitas n comparações. O complexidade analisa o pior caso, ainda mantendo esse algoritmo como O(n). Perceba que se forem feitas diversas buscas em uma lista, o número médio de comparações será entre 1 e N, e cresce proporcionalmente a N, mantendo a característica de complexidade.  A média seria 3n/4 para uma lista não ordenada e n/2 em uma lista ordenada, caso tenha curiosidade.

Um algoritmo para encontrar todos os itens duplicados em uma lista poderia ser escrito assim:

de i := 1 até Lista.Count
  de j := 1 até Lista.Count
    se (i <> j) e (Lista[i] = Lista[j])
      Duplicados.Adiciona(i, j)

Este seria um exemplo de O(n²). Para cada item, todos os outros itens são percorridos. Otimizações simples, como no exemplo anterior, podem ser limitar a iteração no loop interno de 1 até N-1, e no loop interno para a faixa i + 1 até N, que diminuem o número de comparações, mas não alteram a complexidade. O número de iterações ainda é proporcional ao quadrado do número de itens.

Algumas medidas Big-O comuns são as seguintes, em ordem crescente de complexidade:

• O(1), ou constante – O tempo do algoritmo independe do número de itens. Claramente a melhor opção quando N pode crescer muito. É a complexidade em inserção e busca em Tabelas Hash
• O(log n), ou logarítmico - É proporcional ao logaritmo de n, que cresce em uma taxa muito mais lenta que n. É uma opção bem adequada quando não é possível utilizar O(1). A busca binária em uma lista ordenada tem essa complexidade.
• O(n), ou linear - É o exemplo que já vimos de uma busca de força bruta em uma lista qualquer. Começa a ser um problema quando seu código tem que tratar um número indeterminado de itens.
• O(n²), ou quadrática – O número de operações é proporcional ao quadrado do número de itens. O algoritmo intuitivo de ordenação, a ordenação por inserção, tem essa complexidade. Deve ser evitada praticamente para qualquer número de itens que não estejam sobre estrito controle.
• O(n!), ou fatorial – Proporcional ao fatorial de n, ou seja, cresce extremamente rápido. Mesmo que as operações sejam rápidas, rapidamente com o crescimento de n o tempo tomado pelo algoritmo passará a ser excessivamente grande (horas, dias, ou mais). A força bruta de uma senha tem essa essa complexidade, ou a solução do problema do caixeiro viajante.

Conclusão

A complexidade de algoritmos é um ponto importante para ser considerado na escolha do design ou das estruturas usadas na codificação, evitando introduzir problemas de escalabilidade. Para isso, é importante saber estimar a complexidade de um código e reconhecer a complexidade de inserções e buscas em estruturas de dados comuns. Apesar disso, deve-se evitar a tentação de intuitivamente deduzir quais serão os gargalos no momento da codificação e tomar decisão baseadas nessa intuição, prezando a legibilidade acima de tudo. É muito mais fácil localizar e corrigir gargalos depois de ter o código escrito do que localizar e corrigir problemas de estilo.

A partir do Delphi 2006 o gerenciador de memória padrão que acompanha o Delphi passa a ser o FastMM. Quem não trabalha com Delphi 2006 pode baixar o FastMM aqui.

Se você estiver começando agora a desenvolver com Delphi deve estar se perguntando: Tá, e dai? O que é memory leak?

Memory leak é um objeto criado pela aplicação que não foi corretamente destruído.

Você pode simular esta situação criando qualquer objeto no OnCreate do formulário principal da sua aplicação. Exemplo:

procedure TForm1.FormCreate(Sender: TObject);
var
  lstVazamento : TStrings;
begin
  lstVazamento := TStringList.Create;
  try
    lstVazamento.Add('Linha 1');
    lstVazamento.Add('Linha 2');
    lstVazamento.Add('Linha 3');
  finally

  end;
end;

Execute o aplicativo e feche-o. Você notará que não acontece nada!

Esse teste ridículo foi feito só para você ver como é comum ocorrerem problemas que resultem em vazamentos de memória (memory leaks) como a falta de atenção (nesse caso), a pressa, Control+C / Control+V entre alguns outros.

Agora insira esta linha logo após o begin da sua procedure:

ReportMemoryLeaksOnShutdown := True;

Deixando o código assim:

procedure TForm1.FormCreate(Sender: TObject);
var
  lstVazamento : TStrings;
begin
  ReportMemoryLeaksOnShutdown := True;

  lstVazamento := TStringList.Create;
  try
    lstVazamento.Add('Linha 1');
    lstVazamento.Add('Linha 2');
    lstVazamento.Add('Linha 3');
  finally

  end;
end;

Repita a operação e veja o que acontece após fechar o aplicativo:

Veja que recebemos a notificação do TStringList que criamos e das 3 linhas que adicionamos (String x 3) a ele. A partir dai podemos começar a evitar esse tipo de erro na hora de desenvolvermos aplicativos.

Uma dica importante é você utilizar o bloco try…finally…end; sempre que criar um objeto dinamicamente. Isto evita que ocorra um erro no meio da execução e ele não seja destruído devidamente. Veja os dois exemplos:

Método não apropriado:

procedure TForm1.FormCreate(Sender: TObject);
var
  lstVazamento : TStrings;
begin
  ReportMemoryLeaksOnShutdown := True;

  lstVazamento := TStringList.Create;
  lstVazamento.Add('Linha 1');
  lstVazamento.Add('Linha 2');
  lstVazamento.Add('Linha 3');
  lstVazamento.Free;
end;

Método apropridado de utilização:

procedure TForm1.FormCreate(Sender: TObject);
var
  lstVazamento : TStrings;
begin
  ReportMemoryLeaksOnShutdown := True;

  lstVazamento := TStringList.Create;
  try
    lstVazamento.Add('Linha 1');
    lstVazamento.Add('Linha 2');
    lstVazamento.Add('Linha 3');
  finally
    lstVazamento.Free;
  end;
end;

Utilizando o bloco try…finally…end; mesmo que ocorra algum erro na execução do procedimento o objeto é destruído. Pelo método não apropriado lstVazamento não seria destruído caso ocorresse algum problema na execução da linha lstVazamento.Add(‘Linha 1′);, por exemplo.

Em tempo: utilizando ReportMemoryLeaksOnShutdown := True; a mensagem ocorrerá sempre que o aplicativo for terminado, inclusive fora do Delphi. Para evitarmos esse situação, substitua o True por DebugHook <> 0; deixando a linha assim:

ReportMemoryLeaksOnShutdown := DebugHook <> 0;

Para quem utiliza outras versões do Delphi isto deve ser configurado no arquivo FastMM4Options.inc.

No próximo artigo abordaremos mais funções do FastMM e configurações do arquivo FastMM4Options.inc para quem utiliza FastMM em versões mais antigas do Delphi. Até mais!

Exemplo: seu programa utilizou 4.569K e liberou 169K, esse valor é contabilizado pelo windows até que outro programa o utilize (o gerenciador continua mostrando os 4.569K).

A causa desse problema com o gerenciador de tarefas é o gerenciador de memória runtime do Delphi alocar memória indiretamente. Quando o programa solicita memória para o gerenciador, ele aloca blocos de memória para o programa. Os blocos tem tamanho fixo de modo que para cada pedido de memória o gerenciador aloca a quantidade necessária de blocos contínuos para satisfazer o pedido do programa.

Deste ponto de vista o bloco é a menor quantidade de bytes que o gerenciador aloca.

Exemplo: Um bloco tem 16 bytes; se o programa pede 4 bytes, o gerenciador irá alocar um bloco; se o programa pedir 18 bytes, o gerenciador irá alocar dois blocos.

Parece que o gerenciador está “torrando” memória a toa, mas isso é feito para evitar a fragmentação da memória. Quando o programa devolve memória ao gerenciador, este não a devolve para o Windows, pois ele deduz que o programa pode solicitar mais memória a qualquer momento e a reserva para otimizar o tempo de acesso a ela.

Entendendo melhor o funcionamento:

Imagine que você possui duas classes (TAlocaMemoriaAtoa e TAlocaMemoriaAVontade). Quando executamos um programa qualquer, por exemplo, vamos imaginar que o gerenciador aloque 10 blocos de memória. Após isso criamos a classe TAlocaMemoriaAtoa que solicita ao gerenciador mais 10 blocos. O tamanho total de memória utilizada é 20 blocos. Ao destruírmos a classe TAlocaMemoriaAtoa o sistema libera 10 blocos, mas o gerenciador os mantém disponíveis para a aplicação. Se nesse momento criarmos a classe TAlocaMemoriaAVontade e esta solicita 5 blocos de memória, o gerenciador buscará 5 blocos dos 10 reservados anteriormente, quando a classe TAlocaMemoriaAtoa fora destruída.

BINGO! Por isso que quando eu fazia debug da minha aplicação com o gerenciador de tarefas aberto os “Free” e “FreeAndNil” quase nunca funcionavam!

No meu próximo post falarei sobre gerenciadores de memória alternativos como o FastMM, adotado como gerenciador de memória padrão na versão 2006 do Delphi, e faremos alguns testes comparativos. Até a próxima.