Dicas de otimização

É difícil estabelecer um método definitivo para “programar bem”, mas queremos enfatizar nas janelas de estruturar bem os programas. A capacidade de programar estruturadamente em 4D pode ser de grande ajuda.

A compilação de um banco bem estruturada pode obter melhores resultados que em um banco mal estruturado. Por exemplo, se escrever um método genérico para manejar n métodos de objeto, obterá resultados de mais qualidade em modo interpretado e em compilado que em uma situação onde n métodos de objeto compõe n vezes o mesmo conjunto de instruções.

Em outras palavras, a qualidade da programação tem um impacto na qualidade do código compilado.
Com prática, pode melhorar progressivamente seu código 4D. O uso frequente do compilador lhe dá uma retroalimentação corretiva que lhe permite alcançar instintivamente a solução mais eficiente.

Entretanto, lhe podemos oferecer alguns conselhos e truques para que poupe tempo realizando tarefas simples e recorrentes.

Algumas técnicas de programação podem fazer que seu código não seja fácil de ler tanto para você como para outra pessoa no futuro. Por esta razão, lhe aconselhamos comentar detalhadamente seus métodos. De fato, enquanto que os comentários excessivos tendem a deixar lenta um banco interpretado, não tem nenhuma influência no tempo de execução de um banco compilado.

As diretrizes de compilação podem ajuda-lhe a acelerar seu código consideravelmente. Quando declara variáveis com banco em seu uso, o compilador utiliza o tipo de dados com o maior alcance possível para não penalizá-lo. Por exemplo, se não declarar a variável definida pela instrução: Var:= 5, o compilador lhe dará o tipo Real, inclusive se pudesse ser declarada como Inteiro.

Por padrão, o compilador dá o tipo Real às variáveis numéricas não declaradas por diretrizes de compilação e se as Propriedades do banco não indicam outra coisa. Os cálculos com Reais são mais lentos que com Inteiros longos. Se sabe que uma variável numérica sempre será um inteiro, é conveniente declará-la com as diretivas de compilação C_LONGINT.

Por exemplo, é uma boa prática declarar seus contadores de loops como Inteiros.

Algumas funções 4D automaticamente devolvem Inteiros (exemplo: Character code, Int...). Se atribuir o resultado de uma destas funções a uma variável não declarada de seu banco, o compilador lhe atribua o tipo Real ao invés do tipo Inteiro. Lembre de declarar estas variáveis com diretivas de compilação sempre que esteja seguro de que não se utilizarão em um contexto diferente.

Este é um exemplo simples de uma função que devolve um valor aleatório dentro de uma faixa dada:

Sempre devolverá um inteiro. Escrito de esta maneira, o compilador lhe dará a $0 o tipo Real ao invés de Inteiro ou Inteiro longo. É melhor incluir uma diretriz de compilação no método:

e uma terceira variável não declarada recebe a soma das outras duas variáveis:$var3:=$var1+$var2.

O compilador declarará a terceira variável, $var3, como Real. Você terá que declará-la explicitamente como Inteiro longo se deseja que o resultado seja Inteiro longo.

Nota: seja cuidadoso com o modo de cálculo em 4D. Em modo compilado, não é o tipo de variável que recebe o cálculo que determina o modo de cálculo, mas o tipo dos operandos.

• No exemplo a seguir, o cálculo se realiza sobre inteiros longos:

$var3 é igual a –2147483648 tanto em modo compilado como interpretado.

• Entretanto, neste exemplo:

Por razões de otimização, o compilador considera o valor 1 como um inteiro. Em modo compilado, $var3 é igual a –2147483648 porque o cálculo é realizado sobre Inteiro longos. Em modo interpretado, $var3 é igual a 2147483648 porque o cálculo se realiza sobre Reais.

Os botões são um caso específico de Real que pode ser declarada como Inteiro longo.

Se quer provar o valor de um caractere, é mais rápido fazer a comparação com seu valor Character code em vez de com o caractere mesmo. A rotina estandarte de comparação de caracteres leva em conta todas as variações do caractere, tais como as acentuações.

O processamento de arrays de duas dimensões se maneja muito melhor se a segunda dimensão é mais longa que a primeira.

Por exemplo, um array declarado como:ARRAY INTEGER(Array;5;1000)

será manejado melhor que um array declarado como:

Quando necessite efetuar vários cálculos sobre um campo, pode melhorar o desempenho armazenando o valor do campo em uma variável e realizando seus cálculos sobre a variável ao invés de sobre o campo. Considere o seguinte método:

Este método tomará mais tempo em ser executado que se escreve desta forma:

Como no caso dos campos, é mais rápido trabalhar com variáveis que com ponteiros sem referência. Quando necessite realizar vários cálculos sobre uma variável referenciada por um ponteiro, pode poupar tempo armazenando o ponteiro sem referência em uma variável.

Por exemplo, suponha que utiliza um ponteiro, MeuPtr, para fazer referência a um campo ou a uma variável. Você deseja realizar um conjunto de provas sobre o valor referenciado por MeuPtr. Pode escrever:

O conjunto de provas seria realizado mais rápido se escrever:

Utilize variáveis locais, sempre que seja possível, para estruturar seu código. Utilizar variáveis locais tem as seguintes vantagens:

• As variáveis locais ocupam menos espaço quando são utilizadas em um banco. São criadas quando se entra no método onde são utilizadas e são destruídas quando o método termina sua execução.
• O código gerado é otimizado para variáveis locais, especialmente para as de tipo Inteiro longo. Isso é útil para contadores em loops.