Normalmente quando compilamos um aplicativo com a opção “Build with runtime packages” marcada, no mínimo teremos que redistribuir os pacotes rtlxx.bpl e vclxx.bpl (onde o “xx” equivale à versão do Delphi, pelo menos até o Delphi 7), mais os pacotes referenciados pelas units da vcl e/ou de terceiros.

Agora imagine um projeto grande, onde temos vários componentes de terceiros empregados. Quantos arquivos extras se tornariam dependências para o aplicativo?

Procurando uma maneira simples para minimizar o número de arquivos a serem distribuídos em conjunto com um aplicativo que use runtime packages, me deparo com o excelente tutorial de Keith Johnson, ao qual não posso acrescentar muita coisa, por já ser muito completo e didático. Contento-me a simplificá-lo e torná-lo útil para a realidade de muitos aqui.

Direto ao ponto

Figura 1 – Aplicativo com pacotes dinâmicos de forma convencional.

Figura 2 – Aplicativo com pacotes dinâmicos carregando de um único pacote.

Abra o Delphi, crie um novo aplicativo e salve o projeto. Adicione os componentes necessários de forma natural, como se fosse um projeto comum e salve.

Agora você pode fechar seu projeto e criar um novo package, ou criá-lo no mesmo grupo de projetos. Para simplificar, vou usar a segunda opção. Crie uma Unit vazia dentro deste novo package.

Você deverá percorrer TODOS os forms do seu projeto, vasculhando as cláusulas Uses para que todas as units referenciadas sejam adicionadas àquela unit do nosso pacote. Nosso objetivo será fazer com que o pacote importe todas essas units implicitamente para dentro dele, para que o executável tenha apenas ele como dependência. Para isso vá até Project -> Options e escolha a opção “Directories/Conditionals”, altere o “Output directory” e o “DCP directory” para uma pasta onde estará seu executável (o “DCP directory” é necessário na hora da compilação do executável, pois ele vai procurar pelo arquivo .dcp do pacote, mas em tempo de execução, ele só precisará do arquivo .bpl), ou onde ele tenha acesso pelo path do Windows.

É preferível deixar junto ao executável como numa pasta “bin” do seu projeto para facilitar a localização e distribuição, evitando um “bpl hell”. Clique em Ok e vá até aquela unit que você criou dentro do pacote. Adicione uma cláusula Uses a ela e coloque todas as units referenciadas pelo seu aplicativo.

No diretório de saída que você acabou de configurar, coloque uma cópia da SysInit.dcu, que se encontra em $(BDS)\lib (ex: C:\Arquivos de programas\CodeGear\RAD Studio\5.0\lib). Esta unit faz-se necessária, pois se você tentar compilar seu projeto sem ela, vai disparar uma exceção, informando que não foi possível encontrar SysInit.dcu (lembre-se: o search path que você configurou sobrepõe o default do Delphi, daí ele não achar). Mesmo assim, esta unit não deve ser adicionada na sessão uses da unit do pacote, deverá apenas permanecer lá na pasta de destino. Vá até a sessão “requires” do seu pacote lá no Project manager e elimine TODAS as referências a outros packages, deixando-a vazia.

Agora compile seu pacote. Irá aparecer uma mensagem, dizendo que você deve incluir os packages da lista para manter compatibilidade com outros pacotes já instalados.

É agora que vem o segredo: Escolha “Cancel” para que as units referenciadas sejam importadas para dentro de nosso pacote, e não as referências aos seus respectivos packages. Outro diálogo aparecerá com a mensagem: “If these changes are not applied, errors may occur when the package is loaded. Cancel changes?”.

Escolha “Yes” agora. Toda vez que esse pacote for recompilado você deverá seguir estes passos.

Se você verificar o resultado, poderá comprovar um package de até vários megabytes na pasta de destino (em um projeto que temos por aqui, está em torno de 13MB). Então, acabou? Ainda não, só mais uns ajustes no executável.

Considerando que você seguiu meu conselho e criou uma pasta só para os binários (“bin”, onde estarão .exe, .dcp, .bpl), selecione o projeto do executável agora, vá até Project -> Options e escolha a opção “Directories/Conditionals”, lá em “Search path”, coloque o caminho da pasta Bin do seu projeto e faça o mesmo para o “Output directory”.

Ainda nesta tela, escolha a opção “Packages”, marque a opção “Build with runtime pakages” e no Edit, limpe tudo, para adicionar apenas o nome do seu pacote.

Clique em Ok e dê um build no seu aplicativo. Com isso, você já poderá notar uma redução de até 90% no tamanho do executável.

Como já dito antes, para a distribuição do nosso aplicativo teste, apenas os 2 arquivos acima marcados serão necessários.

Conclusão

Quais as vantagens que podemos tirar deste método? Teremos todas as vantagens de se utilizar pacotes dinâmicos em um aplicativo, como velocidade na compilação (lembre-se que na maioria das vezes, você compilará apenas o código associado diretamente ao seu aplicativo, pois o código dos componentes já está embutido no pacote), executáveis e dlls muito menores (muito mais simples e rápido para atualizar seu aplicativo junto aos clientes) e maior facilidade para implementação de plugins, seja com dlls ou bpls. Se você colocar regras de negócio em um pacote ou fizer uso de rotinas muito sigilosas, poderá distribuir apenas os bpls do pacote livremente entre os desenvolvedores do projeto sem medo, pois estará fazendo uso do encapsulamento de código a seu favor.

E as desvantagens? Se você considerar todos os benefícios desta abordagem, o fato de ter que atualizar um pacote de 13MB (se compactar pode cair para 4MB ou 5MB) toda vez que mudar algum componente não pesará tão contra assim.

Este exemplo criou um único pacote com todas as units utilizadas pelo aplicativo, mas se você preferir poderá criar 2, 3 ou quantos pacotes precisar, separando-os por categoria, como pacotes de componentes visuais, acesso a dados, regras de negócio ou outra categoria que for necessária para seu projeto.

Este é o meu primeiro post, e espero que seja útil para quem precisar aplicar tais conceitos.

• Completamente nova engine de JavaScript, chama V8, prometendo performance extremamente superior às existentes.
• Abas isoladas em processos separados, com a finalidade de melhorar a estabilidade e segurança.
• Modelo de segurança onde páginas rodam em uma sandbox especial, sem contato com nada. O ponto fraco ainda são os plugins.
• Renderização de HTML feita pelo WebKit.
• Google Gears integrado
• Várias pequenas melhorias técnicas em relação aos browsers atuais.

O projeto é prometido para ser completamente open source. Acho interessante a engine de JavaScript, em particular, por não ser acoplada ao browser e plugável em outros projetos.

Ainda é extremamente cedo para tirar qualquer tipo de conclusão, principalmente apenas a partir de uma história em quadrinhos, mas tenho a impressão que é um projeto que vale a pena ficar de olho.

Closure é a união do código com o seu escopo. Isso quer dizer que o novo método tem acesso às variáveis locais do método que o criou, mesmo depois que ele terminou. Vamos ver como isso funciona com um exemplo:

type
  TContador = reference to function: Integer;

function CriaContador(Inicial, Final: Integer): TContador;
var
  i: Integer;
begin
  i := Inicial;
  Result := function: Integer
  begin
    Result := i;
    Inc(i);
    if i > Final then
      i := Inicial;
  end;
end;

var
  Contador: TContador;
  i: Integer;
begin
  Contador := CriaContador(5, 12);
  for i := 0 to 20 do
    WriteLn(Contador);
end.

Antes de ver a listagem da saída do programa, Vamos entender o código. TContador é um tipo que representa uma referência a uma função que retorna um número. Neste caso, vai retornar uma sequência de números, um número novo cada vez que for chamada. CriaContador é uma função que retorna um método desse tipo, recebendo os valores inicial e final que a sequência vai ter. Repare que o corpo de CriaContador tem apenas duas linhas de código que serão executadas quando ela for chamada: ela inicializa o contador, e atribui um novo método para o resultado.

No corpo do programa criamos um novo contador na faixa 5 até 12, e chamamos essa função 21 vezes, escrevendo o resultado no console.  Em cada chamada da função, ela retorna o valor atual de i, o incrementa, e caso tenha passado do valor final, volta ao primeiro.

Quais serão os 21 números escritos no console?

5
6
7
8
9
10
11
12
5
6
7
8
9
10
11
12
5
6
7
8
9

Ou seja, o programa funciona exatamente como descrevi.

Cada instância do método captura o escopo daquele momento. Se criarmos dois contadores:

var
  Contador, Contador2: TContador;
  i: Integer;
begin
  Contador := CriaContador(5, 8);
  Contador2 := CriaContador(1, 3);
  for i := 0 to 5 do
    WriteLn(Contador,':',Contador2);
end.

podemos ver que eles funcionam de forma completamente independente:

5:1
6:2
7:3
8:1
5:2
6:3

Essa é uma nova técnica possível no Delphi 2009. Para implementar o equivalente sem este recurso, seria necessário criar classes para o contador, construir instâncias e liberá-las. Ou seja, muito mais código e complicação.

O Craig Stuntz escreveu um exemplo muito interessante utilizando esse método pra implementar o Crivo de Eratóstenes. Ele entrou no assunto da técnica de currying, que vai ficar para o próximo artigo.

type
  TComparaString = reference to function(const S1, S2: string): Integer;

Esse tipo pode ser usado como qualquer outro tipo procedural:

procedure TLista.Ordena(Compara: TComparaString);
var
  i, j: Integer;
begin
  for i := 0 to FItems.Count - 2 do
    for j := FItems.Count - 1 downto i + 1 do
      if Compara(FItems[j], FItems[i]) < 0 then
         Troca(i, j);
end;

(Perdoem-me o Bubble Sort)

Não precisamos mais declarar um método separadamente para cada forma diferente de ordenação que for necessária. O código abaixo ordena uma lista alfabeticamente, depois de forma inversa, e finalmente de acordo com o tamanho da string:

  Lista := TLista.Create;
  try
    Lista.Adiciona('Um');
    Lista.Adiciona('Dois');
    Lista.Adiciona('Tres');
    Lista.Adiciona('Quatro');
    Lista.Adiciona('Cinco');
    Lista.Ordena(function(const S1, S2: string): Integer
                 begin
                   Result := CompareStr(S1, S2);
                 end);
    WriteLn(Lista.Texto);
    Lista.Ordena(function(const S1, S2: string): Integer
                 begin
                   Result := CompareStr(S2, S1);
                 end);
    WriteLn(Lista.Texto);
    Lista.Ordena(function(const S1, S2: string): Integer
                 begin
                   Result := Length(S1) - Length(S2);
                   if Result = 0 then
                     Result := CompareStr(S1, S2);
                 end);
    WriteLn(Lista.Texto);
  finally
    Lista.Free;
  end;

A resultado do programa é:

Cinco
Dois
Quatro
Tres
Um

Um
Tres
Quatro
Dois
Cinco

Um
Dois
Tres
Cinco
Quatro

Até aí, o recurso não é nada demais – permite economizar algumas linhas em troca de uma sintaxe discutivelmente mais confusa. Ele fica realmente interessante quando se nota que é, de fato, uma Closure, que exploraremos no próximo artigo.

Já experimentei diferentes ferramentas, inclusive mantendo algumas customizações no exemplo TextDiff, que acompanha o componente TDiff (que permite embutir esse tipo de comparação na sua aplicação feita em Delphi). Mas sempre gostei mesmo do Beyond Compare, e acabei comprando uma licença cerca de um ano e meio atrás, por um preço bastante razoável.

Semana passada vi que o Beyond Compare tinha lançado a versão 3.0:

A nova versão possui diversos novos recursos, incluindo suporte a Unicode e 3-way merge (que fazia falta no passado).

Fui para o site preparado para comprar a atualização – para minha surpresa eles oferecem atualização grátis para quem comprou uma licença a partir de 1º de janeiro de 2007, quase um ano e nove meses atrás. Preenchi um formulário no site deles e em alguns minutos tinha a chave da nova versão no meu email.

Definitivamente recomendo Beyond Compare para comparação e sincronização de arquivos e pastas, pelos recursos e preço acessível. Qual a ferramenta de comparação que você usa?

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.

Apesar de o principal novo recurso ser o total suporte de Unicode na VCL, vários outros novos recursos chamam a atenção:

• Novos controles na VCL, com destaque ao Ribbons estilo Office 2007.
• Melhorias na ImageList, incluindo suporte a PNG.
• Novos recursos de linguagem, com destaque a Generics e Anonymous Methods.
• VCL pra Web atualizada com suporte a AJAX e Silverlight.
• DataSnap 2009, que simplifica o desenvolvimento de aplicações três camadas sem uso de COM.

Vale a pena conferir a lista de componentes de terceiros que já foram atualizados para ter suporte ao Delphi 2009.

Pretendo detalhar os novos recursos em futuros artigos, portanto aguarde atualizações.

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.

Ontem apresentei uma palestra semelhante na CodeRage II, em português e inglês. A CodeRage ainda está acontecendo (e é grátis!), e algum tempo depois do seu término o replay será disponibilizado na CodeGearTV.

Enquanto isso, se você estiver interessando em mais uma oportunidade de conhecer  o BlackfishSQL, aprender a escrever Stored Procedures e Triggers em Delphi, e fazer perguntas ao vivo, não perca o CodeGear Delphi Day em Português, dia 7 de dezembro. Além da minha apresentação do BlackfishSQL, existem seis outras palestras técnicas, gratuitas, em português.

Se você ainda não conheçe o BlackfishSQL, vou mostrar rapidamente porque você deve assistir minha apresentação.

BlackfishSQL

BlackfishSQL é um banco 100% gerenciado, rodando completamente sobre uma máquina virtual, sem dependências de nenhum sistema operacional. Existem versões de BlackfishSQL para a plataforma Java e para a plataforma .Net. Apesar de ser o primeiro lançamento para plataforma .Net, e a primeira vez que é chamado de BlackfishSQL, é a oitava versão do banco de dados, que existia com nome JDataStore anteriormente, acompanhando o desenvolvimento do JBuilder por um bom tempo. Apesar de ainda termos poucas escolhas de plataforma com .Net, Java existe em praticamente todo lugar e o BlackfishSQL o acompanha em Linux, Solaris, ou no seu celular, por exemplo.

BlackfishSQL suporta o padrão SQL92, conhecido de todos que já trabalham com SQL, tendo uma boa compatibilidade, sem muitas extensões fora do padrão, preferindo prover os recursos adicionais através de stored procedures já embutidas.

Outras caracteristicas importantes são a fácil distribuição de um servidor BlackfishSQL, de uma aplicação que acessa tal servidor, ou de um aplicação que utiliza o BlackfishSQL de forma embutida no processo - não é necessário instalação, registrar DLLs, ou nada disso - é copiar alguns arquivos e rodar.

A caracteristica do BlackfishSQL que vai interessar mais desenvolvedores Delphi é a possibilidade de escrever Stored Procedures, UDFs e triggers em código Delphi (ou reaproveitar seu código Delphi existente como Stored Procedures), e usar o editor e debugger do Delphi para esse desenvolvimento, de uma forma bem fácil.

Se isso parece interessante, não perca o Delphi Day para conhecer o BlackfishSQL de verdade e ver as outras apresentações.