MANUAL PRÁTICO DE PERFORMANCE
By Jorge Luis Bachtold
INTRODUÇÃO
A melhoria de performance, tanto em PROGRESS quanto em qualquer outra linguagem envolve normalmente uma série de fatores. Não existe nenhum comando “mágico” que acrescentado a um programa vai torna-lo muito mais rápido.
Na maioria das vezes, uma melhoria na forma de funcionamento do programa, tornando-o mais “inteligente” e mentornando-os repetitivtornando-o ptornando-ossibilita uma melhtornando-oria substancial de perftornando-ormance.
Entretanto, mesmo os programas corretamente escritos podem se beneficiar de alguns recursos que o PROGRESS disponibiliza para torna-los mais ágeis. São esses recursos que serão analisados a seguir.
VARIÁVEIS
A menos que a aplicação não permita, utilize sempre variáveis NO-UNDO, pois elas não utilizam controle de transações, evitando escritas no arquivo LBI local, o que melhora a performance. Procure também evitar as variáveis LIKE, a menos que essas variáveis sejam utilizadas para exibição de informações na tela. Para variáveis internas, utilize a declaração AS, sem FORMAT nem LABEL.
DEF VAR c-it-codigo AS CHAR NO-UNDO.
Evite também as variáveis SHARED, a não ser que a aplicação exija. Se as chamadas a programas externos forem substituídas por PROCEDURES internas, a utilização de variáveis SHARED/NEW SHARED torna-se desnecessária. Essa técnica será mostrada com mais detalhes mais à frente.
Quando forem utilizadas variáveis do tipo EXTENT, inicialize seu conteúdo com apenas um comando ASSIGN, ao invés de utilizar um loop, o que é muito mais lento.
Certo:
DEF VAR c-it-codigo AS CHAR extent 10 NO-UNDO. ASSIGN c-it-codigo = "A".
Errado:
DEF VAR c-it-codigo AS CHAR extent 10 NO-UNDO. DEF VAR i-cont AS integer NO-UNDO. DO i-cont = 1 TO 10:
ASSIGN c-it-codigo[i-cont] = "A". END.
ASSIGN
Sempre utilize o comando ASSIGN para carregar valores para variáveis/campos. Procure agrupar o máximo de variáveis possíveis em um mesmo ASSIGN.
Certo:
ASSIGN c-it-codigo = "item-1" i-op-codigo = 10 c-cod-roteiro = "rot-1". Errado: c-it-codigo = "item-1". i-op-codigo = 10. c-cod-roteiro = "rot-1". BUFFER-COPY
Este é um comando novo, introduzido na versão 8 do PROGRESS, que possibilita uma boa melhoria de performance, quando bem utilizado. Ele realiza a cópia de valores entre dois BUFFERS de registro, podendo trabalhar inclusive com TEMP-TABLES. Abaixo temos um exemplo típico da utilização do BUFFER-COPY:
DEF TEMP-TABLE tt-item NO-UNDO LIKE item USE-INDEX codigo. FOR EACH item NO-LOCK:
CREATE tt-item.
BUFFER-COPY item TO tt-item. END.
O exemplo acima copia todos os campos da tabela item para uma TEMP-TABLE. Além de executar mais rapidamente, a possibilidade de erros de digitação é muito menor. Basta lembrar que a tabela item possui mais de 200 campos. Um detalhe que vale a pena mencionar, é que os campos da TEMP-TABLE precisam estar definidos exatamente com o mesmo nome dos campos da tabela, pois o BUFFER-COPY não realiza substituição de campos por similaridade. Por exemplo, o campo NR-ORD-PROD e NR-ORD-PRODU vão surtir o mesmo efeito em um comando ASSIGN, mas irão falhar em um comando BUFFER-COPY. Este comando também permite a utilização das cláusulas USING e EXCEPT, permitindo informar quais os campos que deverão ser copiados. Para maiores detalhes, é conveniente consultar o help.
FIELDS
A cláusula FIELDS, também conhecida por FIELD-LIST, permite ao programador definir quais os campos de determinada tabela um comando de busca irá trazer através da rede para a máquina cliente. Este recurso foi introduzido pelo PROGRESS 8 para melhorar a performance em sistemas cliente/servidor. Através dele é possível reduzir bastante o tráfego de rede e consequentemente a velocidade dos programas. A cláusula FIELDS pode ser utilizada com os comandos FOR (FOR EACH, FOR FIRST, FOR LAST) e nas definições de QUERYS.
FOR FIRST/LAST
Os comandos FOR FIRST e FOR LAST podem substituir os comandos FIND FIRST e FIND LAST respectivamente. A grande vantagem do comando FOR é possibilitar a utilização da cláusula FIELDS, que permite definir quais os campos que serão enviados pela rede do servidor para o cliente. A utilização destes comandos deve ser feita com alguns cuidados:
- Caso a tabela a ser lida possua poucos campos e todos ou quase todos os campos serão utilizados após o comando FOR, não é vantajoso utiliza-lo;
- Os campos que não forem incluídos na cláusula FIELDS não estarão disponíveis para uso pelo programa, entretanto o PROGRESS NÃO emitirá mensagens de erro em tempo de compilação. Apenas serão emitidas mensagens de erro durante a execução do programa; - A utilização do FOR com a cláusula FIELDS é vantajosa apenas em ambiente
Cliente/Servidor, onde os registros transitam pela rede. Em ambientes HOST BASED (como o Magnus I), não apresentam nenhuma vantagem.
- Embora o comando permita, NUNCA deve ser utilizada a cláusula BY, pois nem o FOR FIRST e nem o FOR LAST realizam a ordenação antes de retornar o registro. A cláusula BY pode ser utilizada apenas com FOR EACH.
- Utilize FOR FIRST/FOR LAST apenas para leituras NO-LOCK. Para a leitura de registros que serão atualizados, é mais conveniente a utilização do FIND EXCLUSIVE-LOCK.
A sintaxe mais comum para os comandos FOR FIRST/FOR LAST é a seguinte: FOR FIRST item FIELDS (it-codigo perm-saldo-neg pm-ja-calc)
WHERE item.it-codigo = c-it-codigo NO-LOCK: END.
FOR EACH
O comando FOR EACH também permite a utilização da cláusula FIELDS, o que agiliza bastante a execução deste comando. O exemplo abaixo é cerca de 3 vezes mais rápido com a cláusula FIELDS:
FOR EACH item FIELDS (it-codigo) NO-LOCK: END.
Procure aninhar o máximo de leituras possíveis no mesmo comando. Certo:
FOR EACH item FIELDS (it-codigo) NO-LOCK, FIRST estrutura FIELDS (it-codigo)
WHERE estrutura.it-codigo = item.it-codigo NO-LOCK: DISP estrutura.it-codigo.
END. Errado:
FOR EACH item FIELDS (it-codigo) NO-LOCK: FIND estrutura WHERE
estrutura.it-codigo = item.it-codigo NO-LOCK NO-ERROR. IF avail estrutura THEN DISP estrutura.it-codigo. END.
Lembre-se que a cláusula FIELDS e a cláusula NO-LOCK devem ser informadas para cada componente do FOR EACH.
Quando for realizar a atualização de registros, dentro de um FOR EACH, onde apenas alguns registros serão atualizados, procure realizar um FOR EACH com a cláusula NO-LOCK e um FIND EXCLUSIVE-LOCK apenas para os registros que serão atualizados.
FOR EACH item FIELDS (it-codigo pm-ja-calc) NO-LOCK: IF item.pm-ja-calc THEN DO:
FIND b-item WHERE ROWID (b-item) = ROWID (item) EXCLUSIVE-LOCK: ASSIGN b-item.log-1 = yes.
END.
DISP item.it-codigo. END.
Lembre-se de utilizar um BUFFER do registro para realizar a atualização, senão o PROGRESS vai emitir uma mensagem de erro.
FIND CURRENT
O comando FIND CURRENT pode ser utilizado para realizar a atualização de um registro já tenha sido lido com um FOR FIRST.
FOR FIRST item FIELDS (it-codigo) NO-LOCK: IF fn-altera-item (item.it-codigo) THEN DO: FIND current item EXCLUSIVE-LOCK.
ASSIGN item.log-1 = yes. END.
TEMP-TABLES
As TEMP-TABLES, se utilizadas corretamente, possibilitam grande auxílio na melhora de performance dos programas em PROGRESS.
Procure defini-las como NO-UNDO, a menos que seja realmente necessário manter o controle sobre as alterações realizadas dentro das transações. A utilização da cláusula NO-UNDO, além de torna-la mais rápida, ocupa menos espaço em disco na estação do cliente.
Procure ser o mais “mesquinho” possível na criação de índices, pois eles tornam a inclusão de registros mais lenta. Por outro lado, na grande maioria das vezes, é excelente definir um índice primário e único baseado nos FINDS que forem executados no programa.
Não utilize os comandos FOR FIRST, FOR LAST e CAN-FIND para TEMP-TABLES, pois eles não irão proporcionar nenhum ganho de performance, afinal todas as informações da TEMP-TABLE estão armazenadas localmente e não irão transitar pela rede. Da mesma forma, não é necessário utilizar as cláusulas NO-LOCK, SHARE-LOCK ou EXCLUSIVE-LOCK, pois não existe lock de registros para TEMP-TABLES. O PROGRESS simplesmente vai ignorar essas cláusulas.
Sempre que uma TEMP-TABLE for passada como parâmetro, esqueça seu ROWID, pois ele será alterado. Os FINDS com ROWID são os mais rápidos, mas se a TEMP-TABLE for passada como parâmetro será necessário utilizar o índice primário da TEMP-TABLE para posiciona-la.
Procure evitar a criação de TEMP-TABLES LIKE, pois apesar de precisar de menos trabalho para defini-las, elas copiam todas as definições da tabela original, inclusive os índices. Apenas utilize TEMP-TABLES LIKE se realmente precisar de todos ou de quase todos os campos da tabela original.
Se FOR realmente necessária a criação de uma TEMP-TABLE LIKE, utilize a cláusula USE-INDEX, o que fará com que apenas o índice informado seja trazido da tabela original para a TEMP-TABLE.
DEF TEMP-TABLE tt-item NO-UNDO LIKE item USE-INDEX codigo.
Procure evitar a utilização de TEMP-TABLES SHARED e NUNCA utilize TEMP-TABLES GLOBAL SHARED.
USE-INDEX
Procure não utilizar a cláusula USE-INDEX com FIND, FOR EACH e outros comandos de busca de registros, a menos que você realmente queira forçar a utilização de um índice. Em 99% dos casos, o PROGRESS irá selecionar o melhor índice para satisfazer a consulta com a melhor performance possível. Além disso, caso o índice seja modificado, seu programa poderá não mais estar aproveitando ao máximo o índice selecionado, se forem incluídos/modificados ou eliminados campos que faziam parte do índice originalmente.
ROWID
As buscas utilizando o ROWID são as mais eficientes. Sempre que possível, procure utilizar o ROWID da tabela para realizar uma busca. Se o programa permitir, armazene o ROWID utilizado em uma TEMP-TABLE para utilização posterior, caso os mesmos registros sejam acessados várias vezes durante a execução do mesmo.
RUN
O comando RUN permite a execução de PROCEDURES internas, programas externos e chamadas para DLL´s criadas através de outras linguagens. O objetivo deste tópico é analisar as chamadas para programas externos.
Todo programa externo (.P ou .W) reside em disco, não sendo carregado para a memória no momento da execução do programa “pai”. Eles serão apenas trazidos para a memória quando da execução do comando RUN. Dependendo do tamanho do programa a ser chamado, de onde ele está localizado (em um servidor de arquivos da rede, por exemplo) e da velocidade do meio de armazenamento/transporte utilizado, esse tempo pode ser bastante longo. O PROGRESS dispõe de alguns parâmetros de inicialização da seção (por exemplo o –q) que diminuem o tempo necessário para a execução de uma chamada externa. Entretanto, mesmo com um ambiente otimizado, as chamadas externas devem ser evitadas ao máximo.
Um dos mais promissores substitutos das chamadas para programas externos são as PROCEDURES internas (PI´s), que serão tratadas a seguir. Além disso, dependendo da situação, uma boa solução pode ser a utilização de INCLUDES ou a execução de uma chamada em modo persistente, que também serão tratadas a seguir. Como comparativo de performance, seguem abaixo dois exemplos de código. O primeiro utiliza uma chamada para programa externo e o outro utiliza uma PROCEDURE interna.
Exemplo 01: /* A1.P */
DEF NEW SHARED TEMP-TABLE tt-item NO-UNDO LIKE item USE-INDEX codigo. FOR EACH item NO-LOCK:
RUN B1.p (BUFFER item). END.
DEF SHARED TEMP-TABLE tt-item NO-UNDO LIKE item USE-INDEX codigo. DEF param BUFFER b-item FOR item.
CREATE tt-item.
BUFFER-COPY b-item TO tt-item. Exemplo 02:
DEF TEMP-TABLE tt-item NO-UNDO LIKE item USE-INDEX codigo. FOR EACH item NO-LOCK:
RUN pi-grava (BUFFER item). END.
PROCEDURE pi-grava.
DEF param BUFFER b-item FOR item. CREATE tt-item.
BUFFER-COPY b-item TO tt-item. end PROCEDURE
O primeiro exemplo é executado em 29 segundos e o outro em 23 segundos. Vale lembrar que o programa B1.P é bem pequeno. Em condições reais, quanto maior o sub-programa, maior será a diferença de performance.
PROCEDURES
As PROCEDURES internas são uma das mais eficazes armas para melhoria de performance. Além de serem chamadas mais rapidamente, possuem uma série de outras vantagens:
- Podem receber um nome mais explicativo com relação à função que realizam. Por exemplo, o nome PI-CRIA-RESERVAS-ORDEM é bem mais esclarecedor do que CPP/CP0302b.p. - Como elas estão no corpo do programa, todos os BUFFERS e variáveis que forem
declaradas no programa principal poderão ser acessadas pela PI, não precisando receber parâmetros e nem variáveis SHARED.
- Permite a definição de variáveis e BUFFERS locais, o que as torna perfeitas para execuções recursivas.
- Apesar de estarem no corpo do programa, cada PROCEDURE é carregada em seu próprio segmento executável, o que permite que cada uma delas tenha até 64KBYtes de tamanho, como qualquer programa externo.
Uma técnica que torna a programação com PROCEDURES extremamente fácil e estruturada, é utilizada em algumas API´s do módulo de Produção do EMS 2.0, como a API de criação de ordens de produção (CPAPI301) e de reporte repetitivo (CPAPI009). Essa técnica consiste em definir o código das PROCEDURES em INCLUDES e depois incorporar essas INCLUDES ao corpo principal do programa, o que acaba tornando-o bem pequeno e permite uma grande estruturação no código.
INCLUDES
As INCLUDES podem ser utilizadas para substituir as chamadas para programas externos e também para PROCEDURES internas, com algumas restrições. Como o código
contido nas INCLUDES é incorporado ao programa, elas permitem a execução do programa em velocidade máxima, sem perdas de performance por causa de chamadas para programas externos ou PROCEDURES. Entretanto, elas aumentam o tamanho do programa, muitas vezes superando o limite de 64KBYtes por segmento executável. Uma regra básica para as INCLUDES é que devem existir poucas chamadas repetidas para elas dentro dos programas e que devem preferencialmente ser utilizadas em locais extremamente críticos em relação à performance.
PROGRAMAS PERSISTENTES
Uma boa idéia da PROGRESS. Um programa sendo executado de forma persistente nada mais é que um programa externo, rodado através do comando RUN e que retorna um HANDLE para o programa chamador, permanecendo ativo na memória. Através desse HANDLE é possível a execução de qualquer PROCEDURE interna do programa, como se elas fizessem parte do código original do programa pai. Um exemplo bastante conhecido de programa persistente é o UT-ACOMP.P, que é chamado de forma persistente e depois permite a execução de várias PROCEDURES como a PI-ACOMPANHAR e PI-INICIALIZAR. Infelizmente, o recurso de execução persistente não é muito utilizado pelo EMS. Através dele seria possível uma maior separação da interface das regras de negócio, disponibilizando PROCEDURES dentro das API´s para realização de validações, verificações de saldo e outras tarefas que são realizadas pelos programas com interface antes da efetiva chamada da API.
Além disso, o PROGRESS permite a execução de programas persistentes em um servidor RPC, realizando AS chamadas das PROCEDURES diretamente ao servidor, de forma transparente para o programa, tornando a execução ainda mais rápida.
A sintaxe mais comum para execuções persistentes é: RUN cpp/cpapi001.p PERSISTENT SET h-handle.
CAN-FIND
A função CAN-FIND retorna um valor lógico YES caso encontre o registro informado. O CAN-FIND deve sempre ser utilizado quando apenas é necessária a confirmação da existência ou não do registro, pois executa de forma mais rápida do que o FIND ou o FOR FIRST. Como a verificação da existência do registro é feita no servidor, não haverá nenhuma informação transitando pela rede a não ser um valor lógico YES ou NO, o que é bem mais rápido do que o envio de um ou mais campos da tabela como acontece com o FIND ou o FOR FIRST.
SHARE-LOCK
Evite utiliza-lo. Como o default do PROGRESS para os comandos FIND e FOR é SHARE-LOCK, deve-se sempre acrescentar AS cláusulas NO-LOCK ou EXCLUSIVE-LOCK quando for o caso.
BUFFER
Sempre que for necessária a utilização de um registro em uma PROCEDURE ou um sub-programa externo, utilize a passagem do BUFFER como parâmetro, em vez de passar o ROWID e realizar um FIND por esse ROWID.
Certo:
/* A1.P */
FOR FIRST item FIELDS (it-codigo) NO-LOCK: END. RUN B1.P (BUFFER item).
/* B1.P */
DEF param BUFFER b-item FOR item. DISP b-item.it-codigo.
Errado: /* A1.P */
FOR FIRST item FIELDS (it-codigo) NO-LOCK: END. RUN B1.P (INPUT ROWID (item)).
/* B1.P */
DEF INPUT param rw-item AS ROWID NO-UNDO.
FIND item WHERE ROWID (item) = rw-item NO-LOCK. DISP item.it-codigo.
Deve-se lembrar que se um registro é lido com NO-LOCK, ele permanecerá com o mesmo estado também no programa B1.P. O mesmo vale para a cláusula FIELDS, que mantém o efeito no sub-programa. No exemplo acima, apenas o campo it-codigo está disponível tanto no A1.P quanto no B1.P.
Uma restrição à utilização de PARAM BUFFER é que não é possível passar o BUFFER para programas executados via RPC.
WORK-FILES
Os WORK-FILES ou WORK-TABLES possuem algumas vantagens de performance em relação às TEMP-TABLES, entretanto possuem várias deficiências que restringem o seu uso a apenas algumas situações. A principal deficiência é não permitir a utilização de índices e nem a realização de FIND para registros específicos, permitindo apenas a movimentação seqüencial, com FIND NEXT/PREV/FIRST/LAST embora permita o posicionamento de forma aleatória utilizando-se o ROWID. Como vantagem, destaca-se a velocidade na criação de registros, um pouco superior à das TEMP-TABLES. Como os WORK-FILES são armazenados exclusivamente em memória, não é possível a utilização dos mesmos para armazenamento de uma grande quantidade de registros. Outra desvantagem é não poderem ser passados como parâmetros.
A utilização mais óbvia para os WORK-FILES seria em uma aplicação que iria criar registros de forma seqüencial, realizando depois a leitura dos mesmos também de forma seqüencial, na mesma ordem.
CASE
Um comando extremamente interessante e também pouco utilizado. O CASE é mais rápido que uma série de comandos IF...THEN...ELSE aninhados e possibilita uma estruturação maior no programa.
Certo: CASE n:
WHEN 1 THEN RUN pi-proc-1. WHEN 2 THEN RUN pi-proc-2. OTHERWISE RUN pi-proc-3. END CASE. Errado: IF n = 1 THEN RUN pi-proc-1. ELSE IF n = 2 THEN RUN pi-proc-2 ELSE RUN pi-proc-3.
IF...THEN...ELSE
O comando IF, em algumas situações pode ser substituído pelo CASE. Em outras não. Uma forma de utilização que embora facilite bastante tem reflexos negativos na performance é a combinação dos comandos ASSIGN e IF (em determinadas situações). O exemplo abaixo ilustra bem isso:
Certo:
IF x = 1 THEN ASSIGN n = 0.
Errado:
ASSIGN n = IF x = 1 THEN 0 ELSE n.
Além disso, deve-se evitar a utilização das constantes lógicas com o comando IF, conforme ilustrado abaixo:
Certo:
IF l-teste THEN RUN pi-teste.
IF NOT l-teste THEN RUN pi-nao-teste. Errado:
IF l-teste = yes THEN RUN pi-teste. IF l-teste = no THEN RUN pi-nao-teste.
Obs.: Nos comandos de busca (FIND, FOR) não deve ser utilizado o operador NOT, sob pena do PROGRESS realizar uma busca em toda a tabela.
INDEXED-REPOSITION
Essa opção, existente nas QUERYS e SMART-QUERYS do PROGRESS, torna a navegação muito mais rápida. Ela não pode ser utilizada se houverem JOINS na QUERY.
TRIGGERS
Existem muitas tabelas importantes do EMS que possuem TRIGGERS de WRITE, CREATE e DELETE. Uma das mais conhecidas é a tabela item que possui uma TRIGGER de WRITE bastante complexa. Esses programas são executados toda vez que o evento correspondente é executado em uma tabela. Por exemplo, a TRIGGER de WRITE do item é executada toda vez que alguma informação é alterada nessa tabela. Em muitos casos isso reduz bastante a performance. Dependendo da aplicação, os campos a serem modificados não tem qualquer interferência na lógica da TRIGGER, entretanto ela é executada assim mesmo. Uma melhoria de performance considerável pode ser conseguida desabilitando-se as TRIGGERS das tabelas que estão sendo atualizadas. Uma forma de fazer isso pode ser vista abaixo:
Este código irá criar uma TRIGGER “vazia” que sobrepõe a execução da TRIGGER original, evitando que esta seja executada.
Obs.: Tenha cuidado na hora de desabilitar as TRIGGERS. Verifique se realmente isso vai prover um ganho significativo de performance e se você não estará desativando regras de negócio importantes para o produto.
ÍNDICES
A correta utilização dos índices das tabelas é uma das formas mais eficientes de melhoria de performance. Existem várias regras para um bom aproveitamento dos índices. Vamos analisar todas elas:
- Quando realizar a busca de um registro utilizando um índice composto de vários campos, sempre procure utilizar EQUALITY MATCHES, ou seja, condições com o sinal de igual (“=”), na mesma seqüência em que são definidos no índice.
Ex.: Índice código, da tabela oper-ord, do banco MGIND: nr-ord-prod, it-codigo, cod-roteiro, op-codigo.
Procure sempre utilizar o máximo possível de EQUALITY MATCHES, a partir do primeiro componente do índice:
Adequado:
FOR EACH oper-ord
WHERE oper-ord.nr-ord-prod = i-nr-ord-prod NO-LOCK:
Melhor:
FOR EACH oper-ord
WHERE oper-ord.nr-ord-prod = i-nr-ord-prod AND oper-ord.it-codigo = c-it-codigo
NO-LOCK: Rápido:
FOR EACH oper-ord
WHERE oper-ord.nr-ord-prod = i-nr-ord-prod AND oper-ord.it-codigo = c-it-codigo AND oper-ord.cod-roteiro = c-cod-roteiro
NO-LOCK: Muito Rápido:
FOR EACH oper-ord
WHERE oper-ord.nr-ord-prod = i-nr-ord-prod AND oper-ord.it-codigo = c-it-codigo AND oper-ord.cod-roteiro = c-cod-roteiro AND oper-ord.op-codigo = i-op-codigo
NO-LOCK:
FOR EACH oper-ord
WHERE oper-ord.nr-ord-prod = i-nr-ord-prod AND oper-ord.cod-roteiro = c-cod-roteiro AND oper-ord.op-codigo = i-op-codigo
NO-LOCK:
No exemplo acima, o PROGRESS apenas utiliza o primeiro componente do índice, não podendo utilizar os demais por causa da quebra de seqüência nos campos do índice. Esse exemplo é especialmente lento, podendo ser inclusive mais lento do que o exemplo abaixo: FOR EACH oper-ord
WHERE oper-ord.nr-ord-prod = i-nr-ord-prod NO-LOCK:
IF oper-ord.cod-roteiro <> c-cod-roteiro or
oper-ord.op-codigo <> i-op-codigo THEN NEXT.
NUNCA realize uma busca sem utilizar pelo menos o primeiro campo de um índice qualquer
da tabela, mesmo que os demais campos não correspondam aos campos do índice. No exemplo acima, nunca deveria ser realizado um FOR EACH na tabela oper-ord sem a utilização do campo nr-ord-prod, a não ser que exista outro índice que permita esse tipo de busca.
- INEQUALITY MATCHES (“<>”) devem ser evitados ao máximo, sob pena de obrigarem a varredura seqüencial de toda a tabela. Se for realmente necessária a utilização do operador lógico <>, utilize-o em um campo que não corresponda ao primeiro componente do índice utilizado. No nosso exemplo da tabela oper-ord, ele poderia ser aplicado para qualquer campo menos o nr-ord-prod, sendo que quanto mais abaixo na estrutura do índice, melhor. Ou seja, a utilização do operador lógico <> no campo op-codigo impacta muito menos na performance do que a utilização no campo it-codigo.
- RANGE MATCHES (“<”, “>”, “<=”, “>=”, “BEGINS”) seguem a mesma recomendação dada para o operador lógico <>. Deve-se evitar utiliza-los nos primeiros componentes do índice, e
NUNCA aplica-los ao primeiro campo do índice, mesmo que para os demais campos sejam
utilizados EQUALITY MATCHES.
- EVITE a utilização da função MATCHES, que não faz aproveitamento dos índices
- A ordem dos campos na cláusula WHERE não importa, desde que a seqüência de componentes do índice seja mantida.
FOR EACH oper-ord
WHERE oper-ord.nr-ord-prod = i-nr-ord-prod AND oper-ord.it-codigo = c-it-codigo
NO-LOCK: Equivale a:
FOR EACH oper-ord
WHERE oper-ord.it-codigo = c-it-codico AND oper-ord.nr-ord-prod = i-nr-ord-prod
NO-LOCK:
- Se for necessário utilizar a cláusula BY em um FOR EACH, procure sempre informar um campo que seja o primeiro componente de um índice.
- NUNCA utilize um IF...THEN...ELSE em uma cláusula WHERE, sob pena de obrigar o
PROGRESS a realizar uma busca seqüencial na tabela. Utilize variáveis auxiliares para receber um valor conforme a condição e realize a busca com essas variáveis.
- Procure evitar ao máximo a utilização do operador lógico OR em uma cláusula WHERE.
Regras para seleção de índices:
Se múltiplos índices não podem ser selecionados, o PROGRESS segue as seguintes regras para escolher um índice:
1) Um índice não é utilizado (ou necessário) se for fornecido um ROWID.
2) Se a opção USE-INDEX é especificada, o PROGRESS utiliza o índice informado. 3) Se a opção CONTAINS é usada, ele seleciona o WORD-INDEX.
4) Se um índice é único e todos os componentes desse índice são comparados utilizando-se EQUALITY MATCHES (“=”) e o outro índice é não-único, o PROGRESS escolhe o índice único.
5) O índice com maior número de EQUALITY MATCHES (“=”).
6) O índice com uma comparação BEGINS (porque BEGINS é considerada como 2 RANGE MATCHES)
7) O índice com maior número de RANGE MATCHES
8) O índice com o critério de ordenação (BY). Isso acontece apenas se a cláusula WHERE não prover informações suficientes para a seleção de outro índice.
9) Pelo nome do índice, em ordem alfabética. 10) O índice primário.
DICAS DE PERFORMANCE
- NUNCA utilize as INCLUDES de tradução (ut-liter, ut-table, ut-field) dentro de loops. Sempre
que for necessária a utilização de literais dentro de um loop ou de um FOR EACH, utilize variáveis para conter as literais e realize o ASSIGN dentro do loop com essas variáveis. Certo:
{utp/ut-liter.i Literal}
ASSIGN c-liter = return-value. FOR EACH item NO-LOCK:
CREATE tt-item.
BUFFER-COPY item TO tt-item ASSIGN tt-item.msg = c-liter. END.
Errado:
FOR EACH item NO-LOCK: CREATE tt-item.
{utp/ut-liter.i Literal} BUFFER-COPY item TO tt-item
ASSIGN tt-item.msg = return-value. END.
Isso degrada a performance porque dentro da INCLUDE ut-liter (e da ut-field e ut-table também), existe uma chamada para um programa externo, que como já vimos, acaba degradando a performance.
- Procure tornar o programa mais “inteligente”. Por exemplo, em um programa que realiza várias atualizações repetidas na tabela saldo-estoq, é interessante armazenar o ROWID utilizado da primeira vez e depois realizar a busca do saldo utilizando-se desse ROWID. - Caso realmente não seja possível a melhoria da performance do programa para os níveis
desejados pelo usuário, procure dar-lhe algum feed-back, ou seja, um retorno do que está acontecendo durante o processo. Essa dica não aumenta realmente a performance do programa, mas faz com que o tempo passe mais rápido para o usuário: é muito mais agradável para ele esperar dois minutos de processamento e acompanhar o que está sendo feito do que ficar dois “longos” minutos olhando para a ampulheta do windows.
- Procure utilizar o máximo de condições possíveis no WHERE, mesmo que essas condições não façam parte do índice, desde que preferencialmente sejam “EQUALITY-MATCHES”, ou seja, utilizem o operador lógico “=”, evitando o uso do NEXT.
Certo:
FOR EACH ord-prod
WHERE ord-prod.nr-ord-prod >= i-ord-ini AND ord-prod.nr-ord-prod <= i-ord-fim AND ord-prod.valorizada = no NO-LOCK: DISP ord-prod.nr-ord-prod.
END. Errado:
FOR EACH ord-prod
WHERE ord-prod.nr-ord-prod >= i-ord-ini AND ord-prod.nr-ord-prod <= i-ord-fim NO-LOCK:
IF ord-prod.valorizada THEN NEXT. DISP ord-prod.nr-ord-prod.
END.
- NUNCA utilize funções na cláusula WHERE nos campos da tabela sendo procurada. Utilize
as funções sempre nos valores a serem localizados. Certo:
FOR EACH movto-estoq
WHERE movto-estoq.dt-trans = DATE (c-data) NO-LOCK: END.
Errado:
FOR EACH movto-estoq
WHERE STRING (movto-estoq.dt-trans) = c-data NO-LOCK: END.
O segundo FOR EACH será executado de forma muito mais demorada, pois o PROGRESS não pode saber o resultado da função sem antes testa-la com todos os registros. Ou seja, o PROGRESS irá realizar uma busca seqüencial em toda a tabela.
- Não utilize RAW-TRANSFER para passagem de parâmetros. O comando RAW-TRANSFER é útil apenas quando for necessária a compactação de todo um registro de uma tabela ou TEMP-TABLE em um campo RAW. Em aplicações normais, deve-se utilizar a passagem de parâmetros e TEMP-TABLES tradicional.
- Existem situações, com SMART-QUERYS muito complexas, em que os programas do EMS apresentam uma navegação extremamente lenta. Nesses casos, pode ser possível a “quebra” da QUERY original em duas ou mais QUERYS menores, com um link de RECORD entre elas. Esse tipo de solução não pode ser utilizada sempre, dependendo de cada caso, mas pode auxiliar bastante na performance, pois diminui o número de JOINS na QUERY e pode permitir a utilização do parâmetro INDEXED-REPOSITION.
- Quando um BROWSE tiver uma QUERY com várias condições OR ou tiver condições que não utilizam índices, pode ser interessante transforma-lo em FREEFORM e utilizar um IF ou um CASE para determinar qual o OPEN QUERY que será utilizado. Esse código é colocado na TRIGGER de OPEN-QUERY IF l-nao-iniciadas AND l-liberadas AND l-alocadas AND l-separadas AND l-requisitadas AND l-iniciadas AND l-finalizadas AND l-terminadas THEN
OPEN QUERY {&SELF-NAME}
FOR EACH tt-niveis NO-LOCK, ~
EACH ord-manut WHERE ord-manut.cd-tag = tt-niveis.cd-tag-pai NO-LOCK BY ord-manut.dt-manut.
ELSE
OPEN QUERY {&SELF-NAME}
FOR EACH tt-niveis NO-LOCK, ~
EACH ord-manut WHERE ord-manut.cd-tag = tt-niveis.cd-tag-pai AND (( ord-manut.estado = 1 AND l-nao-iniciadas ) or
( ord-manut.estado = 2 AND l-liberadas ) or
( ord-manut.estado = 3 AND l-alocadas ) or ( ord-manut.estado = 4 AND l-separadas ) or ( ord-manut.estado = 5 AND l-requisitadas ) or ( ord-manut.estado = 6 AND l-iniciadas ) or ( ord-manut.estado = 7 AND l-finalizadas ) or ( ord-manut.estado = 8 AND l-terminadas ) )
NO-LOCK BY ord-manut.dt-manut.
- Lembre-se que um programa deve ser rápido também no cliente, e não apenas durante o desenvolvimento. Muitas vezes, a forma de utilização ou a carga de trabalho a que o programa é submetido no cliente influencia bastante na performance do mesmo. Um fator que costuma ter grande importância em relação à performance é o travamento (lock) de registros. Muitas vezes um programa é bem rápido quando executado em ambiente de desenvolvimento, mas torna-se bastante lento no cliente, por causa do travamento de registros, quando existem dois ou mais usuários operando o mesmo programa simultaneamente.
Procure travar os registros para atualização durante o menor tempo possível. Procure também evitar que o programa pare devido a um registro travado, quando ele tem a possibilidade de processar outros registros.
Deve-se entretanto, tomar alguns cuidados ao realizar a implementação acima, evitando a ocorrência de dead-locks. Um bom exemplo de código “inteligente”, que evita ao máximo o
travamento de registros e a ocorrência de dead-locks é a API de geração de movimento de estoque CEP/CEAPI001.P, que incorpora, inclusive, o conceito de time-out para execução em RPC, evitando que um registro fique travado permanentemente.
