Hstadler escreveu:Em virtude do seu esclarecimento sobre o desempenho do Clipper em XP, como faço pra poder melhorar essa performance, pois compilei com o timeslice, uso clipper 5.2
pra vc ter uma ideia, eu tinha no arq de NF 12000 registros, fiz uma limpeza e deixei somente com 336 (exatamente), ok, quando abro a tela para fazer uma nova nota, há uma certa demora na mudança de campos, isto é dou um ENTER e demora para ele ir pro outro campo, sem contar quando vc quer pular partes das notas com ESC, fica dificil de aceitar
Felizmente hoje estou com mais tempo e posso discorrer sobre o assunto com mais tranquilidade.
O desempenho do sistema como um todo sofre influência de diversos fatores. Da forma como você falou: simplesmente mudando de um campo para outro, não conheço. Nunca passei por isso. Mas vou tentar enumerar o que me lembro que causa lentidão num programa Clipper, de acordo com as experiências que vivi.
1) LISTA GET COM CENTENAS DE CAMPOS
Uma das coisas que me custou uma boa carga de trabalho. O cliente reclamava que a montagem da lista de GETs era lenta, e ficava mais lenta com o tempo, até que o programa abortava. Descobri que a culpa era, em parte, da função _GET_(), escondida no comando de criação dos campos GET. É ela quem cria cada pseudo-objeto GET. Cada campo, portanto, resultava numa chamada a essa função. Como haviam centenas de campos, era natural que houvesse uma grande demora. Isso eu resolvi modificando o GetSys (rotina que controla a lista GET) para utilizar um único objeto GET para todo o sistema. Assim, _GET_() era usada uma única vez. Nesse ponto, fim do problema de lentidão na montagem da lista. Mas, infelizmente, o uso desse artifício não é nada fácil para quem não tem intimidade com a GetSys().
2) FRAGMENTAÇÃO DE MEMÓRIA
Um bug no sistema de "garbage collector" do Clipper faz com que ele não apenas não funcione, mas consuma um excessivo tempo de CPU. O consumo de CPU, como você já sabe, resolve-se com a função FreeTSlice(). Ela faz diferença na liberação do tempo de uso da CPU. Mas FreeTSlice() não resolve (e nem pretendia resolver) o problema da fragmentação da memória, que continua consumindo recursos do sistema, uma vez que a cada instante, mais swaps em disco continuam sendo necessários, por falta de memória no "heap". Resolvi isso com uma chamada a função Memory(-1) em pontos estratégicos do sistema: imediatamente depois do descarte de matrizes e fechamentos de arquivos de dados (que internamente utilizam matrizes). Ou até mesmo antes da criação de matrizes e aberturas de arquivos. O parâmetro -1, não documentado, força o Clipper a, finalmente, fazer o "garbage collector" que, afinal de contas, funciona. O problema dele está apenas na forma do "gatilho" que o faz funcionar. Nativamente, pelo tempo ocioso do sistema, ele não funciona. O jeito então é chamá-lo de forma direta, através de Memory(-1) nos pontos mais estratégicos do programa.
Para a melhoria do sistema e torná-lo mais eficiente, principalmente no quesito gerenciamento de memória,...
3) LINKER PARA O MODO PROTEGIDO DE MEMÓRIA
Li na outra mensagem que você ainda utiliza o RTLink. Esse linker já teve seus dias. Nos dias de hoje, e já há um bom tempo, o BLinker é considerado imbatível nesse ponto. Além de você poder utilizar vários recursos extras que ele dispõe (a alternativa ao comando RUN é uma que se detaca), você também poderá montar seus programas para o uso do modo protegido. A vantagem nesse modo é que o programa passa a utilizar toda a memória da máquina, esquecendo de vez o limite de 640KB. Ou seja, seu programa não utiliza mais a memória num plano segmentado. Ele passa a ver a memória como um plano linear. Mais memória disponível significa que swaps em disco tornam-se desnecessários na maior parte dos casos, o que resulta num aumento da velocidade de execução.
Esses três ítems se referem aos problemas básicos do Clipper com manipulação de memória. Nenhum deles deve se encaixar no seu problema de lentidão na troca de campos. Mas imagino que seu problema possa estar relacionado não aos campos em si, mas no que é feito "durante" a troca de campos, quando executada, por exemplo, a função relacionada à cláusula VALID e/ou WHEN. Se você tiver algum processamento "mais pesado" em um desses ou nesses dois pontos, a troca de campos se tornará naturalmente mais lenta. O gargalo pode estar aí. Não posso dizer muita coisa sem ver seu código. Até porque, você não especificou se isso ocorre em todos os campos em todas as listas GETs, ou em alguns poucos.
Adicionalmente aos ítens que normalmente causam lentidão nos programas Clipper, dá pra citar também os relacionados aos índices. Como na outra mensagem você diz que ainda usa NTX, resolvi incluir mais esse ponto.
4) ARQUIVOS DE ÍNDICES NATIVOS (NTX)
Isso é uma coisa que ninguém discute: indíces NTX são extremamente mais lentos que os índices compostos/compactados (ex: SIX), além de ser menos confiáveis. Aconselho fortemente a troca pelos índices NSX/CDX que são muito mais rápidos e seguros, e possuem recursos adicionais que trazem muito mais conforto e segurança para o programador. Faça uma busca na pesquisa do fórum. Certamamente alguns links serão mostrados. Esse assunto já foi debatido várias vezes.
E, voltando ao assunto "sistema operacional", volto a frisar que a versão do sistema operacional não influi na performance do programa Clipper. Mesmo que se trate de um sistema operacional que emule o DOS. Tudo funciona de forma absolutamente normal, como sempre foi. Problemas de performance normalmente tem relação com os ítens que enumerei ou, em casos mais graves, com a forma da codificação utilizada. Mas nesse caso, o problema é pontual, não genérico, como parece ser o seu caso.
Espero que tudo o que eu disse possa ajudá-lo de alguma forma a resolver senão todo, pelo menos parte do seu problema.
[]'s
Maligno
http://www.buzinello.com/prg