Velocidade Clipper x xHARBOUR

marcos.gurupi · Mensagem por **marcos.gurupi** » 17 Fev 2006 12:16

Caros, estou convertendo ou melhor já conferti (para efeito de estudo) um dos principais sistemas meus para xharbour, e fiz uma comparação de velocidade executando o mesmo relatório:

Relatorio de sugestao de compra com itens mais vendidos.
1o. O sistema separa os pedidos q foram feitos entre esses periodos e grava em um arq. temp. localmente.
2o. Com o numeros dos pedidos já separados o sistema verifica quais os itens estaum nesses pedidos.
3o. Grava esses itens em um arq. temp. localmente e org. pelo nome do item, podendo assim contar quantos itens foram vendidos
4o. Grava em outro arq. temp. o item pela ordem inversa de quantidade vendida para q o primeiro seja o mais vendido.

Bom, com todo esse processo o sistema em clipper fica em media 2 min mais rápido q o compilado com xharbour, veja bem no clipper uso o clipper 5.3, blinker 7 e cdx por outro lado uso o xharbour + bcc55 (modo console) linkeditado com hbmake e tb com cdx.

Clipper+Blinker: 0:55:35 segundos
Xharbour+llink32: 2:58:16 minutos

Isso executando o programa em rede com o hub 10/100 e o servidor win/2000

Pelo q eu pude observar quando o clipper estah gravando os dados ele grava sem interrupção continuamente e com muita rapidez, o mesmo processo no programa xharbour ele tb grava rapidamente mas apresenta algumas paradas no processo de gravação.

Eu tb observei com o monitor de rede q vem com servidor 2000 q com o xharbour a carga na rede eh menor mas em compesação a velocidade foi muito diferente.

Alguem saberia dizer pq o clipper c comportou melhor?

Mensagem por **vagucs** » 17 Fev 2006 12:33

Se usa o WINDOWS 98 no terminal, a perda de velocidade se dá por que, o console do Windows 98 não tem uma boa interface de programação não, pois todo caractere que vc coloca na tela implica no redesenhamento de toda a tela, ou seja, se durante o relatorio vc coloca apenas 1 numerou ou barra de progreção na tela, toda a velocidade fica comprometido, isto para modo console, nos windows mais novos isto não acontece e o ganho de velocidade é expressível.

Use a GTWVT no windows 98 que ai o que iria para o console vai para uma tela natural do windows e funciona muito mais rapido.

marcos.gurupi · Mensagem por **marcos.gurupi** » 17 Fev 2006 13:20

Caro, fiz o teste com o gtwvt, ou seja, o mesmo teste usando a lib grafica gtwvt, o tempo foi para 3:42 segundos ficando ainda mais lento, fiz tb o teste no win2000 e o clipper ainda sim ficou mais rapido.

Observei q a diferença de velocidade c da quando o sistema estah gravando os dados, ou seja, quando o clipper grava os dados isso eh continuamente e bem veloz, quando eh o sistema em xharbour tem a mesma rapidez mas tem algumas paradas ou pausas, o resultado no final eh a diferença de mais de 2 minutos no meu teste.

Marcos Roberto

marcos.gurupi · Mensagem por **marcos.gurupi** » 17 Fev 2006 17:23

Para acresentar os testes o vagner nunes me disse q achava estranho essa diferença de velocidade pois ela deferia ser ao contrario, pois um sistema q ele converteu na indexacao c gastava 40 min para fazer convertendo para o xharbour isso ficou em 1 min. Por curiosidade eu tb fiz meu teste aqui.

Com o sistema trabalhando localmente e em clipper gastou 46:26 segundos.
Com o sistema em xharbour console isso ficou em 27:14 segundos.
Com o sistema em xharbour+gtwvt ficou em 8:37 segundos.

Realmente com a criação de indice a melhoria foi muito grande, mas n tive sucesso com a gravação de dados.

Marcos Roberto.

mou321 · Mensagem por **mou321** » 02 Mar 2006 13:08

Eu tive um problema Semelhante .....

resolvi nao utilizando o COMMIT

Mauricio

marcos.gurupi · Mensagem por **marcos.gurupi** » 02 Mar 2006 13:36

Acredito q n utilizando o commit/dbcommit() vc terah varios outros problemas. Eu uso o dbcommit() tive mais velocidade com formatação ntfs e n tive nenhum problema com os antigos fat32 entaum mudei para dbcommit() acontece q no teste utilizei somente compiladores diferentes e tive mais performace com o clipper. MISTERIO!!!!

Mensagem por **vagucs** » 02 Mar 2006 13:57

O maior problema de lentidão em rede sempre é o uso excesivo de commits.

o comando COMMIT que depois vira DBCOMMIT() sempre grava as mudanças buferizadas da área atual selecionada.

o comando COMMIT ALL que depoois de pré-processador vira DBCOMMITALL() faz a gravação do buffer de todos os handles de arquivos abertos.

Logo, em um relatorio que vc gire todo o banco de dados e faça leitura e gravação, dê apenas um DBCOMMITALL no final, isto se vc não trabalha abrindo e fechando os arquivos.

Sempre, em qualquer situação, coloqueo os comandos de comitação em pontos estratégicos, além do mais, está é a forma certa de se trabalhar e garantirá mais velocidade ao sistema.

marcos.gurupi · Mensagem por **marcos.gurupi** » 02 Mar 2006 14:15

Aqui em minha regiao (Tocantins) tenho q trabalhar com o dbcommit() no final de cada replace... ou seja, quando vou incluir eu travo o arq. uso o replace e depois o dbcommit() na alteracao eu travo o registro uso o replace e depois dbcommit(), pois acontece varios pigue d energia e muitos clientes n tem no-break tive muitos problemas quando tirei o dbcommit().

mou321 · Mensagem por **mou321** » 02 Mar 2006 14:30

Caro Marcus..

No xharbour Se for uma operacao de Gravação de Muitos Registros eu Somente dou o COMMIT DEPOIS DE FINALIZADA A GRAVAÇAO ou faço uma varicao a cada Xtempo....

Eu quase certeza que no modo de acesso 32 bits o windows interpreta o COMMIT como gravação de buffers GERAL e não só da sua aplicação..

Minha opnião..

mauricio

Mensagem por **vagucs** » 02 Mar 2006 15:43

Ao final de cada replace vc tem mesmo que usar o commit, mas quando se tratar de um processo em lote, apenas uso o commit no final deste processo, ou seja, no final de Whiles, For, etc...

Sem mais
Wagner Nunes
www.vagucs.com.br