Migração Clipper para Harbour Ficou Mais Lento

[developer]

Pessoal, estou com uma situação no mínimo interessante.
Peguei um sistema legado 16 bits (Clipper 5.02) com 300 fontes (.PRG) e 247 banco de dados (.DBF) para converter para Harbour, consegui fazer numa boa, preservando o máximo do código original, adicionando algumas coisas para fazer funcionar no Harbour, o mínimo indispensável ( SETMODE(25,80), PROC MAIN(), RETURN ) só usei GTWVG para poder ter um pouco de melhoria em alguns recursos, poder expandir, etc... e funcionou, ficou muito bom, rodando em Windows 64bits.

O que ficou estranho é que, ficou mais lento!
Não nota-se quase diferença na navegação, cadastros, etc... mas quando precisa calcular bastante para alguma consulta como: Calculo de comissão de vendedores, aí a coisa fica evidente, no Clipper fica 1,5x mais rápido do que no Harbour para os mesmos dados (exatamente os mesmos DBF).

O código fonte é antigo, de mais de 20 anos, mas funciona, não queria mexer no fonte, mas talvez vou ter que fazer alguma coisa pois ficar mais lento é inaceitável...
Não vou nem postar o código aqui, o desta rotina tem mais de 1000 linhas, é longo, feio e mal estruturado, não foi eu quem fez, mas já estava funcionando 100%, portanto desconfio que seja outro problema.

O que eu fiz até agora para tentar resolver:
Apaguei todos arquivos temporários, apaguei todos os ínices (.NTX) - eram 470 no total.
Gerei todos NTX de novo no Harbour (talvez ajudasse pois nos cálculos ele gera arquivos temporários em DBF).
Compilei em 64 bits, depois em 32 bits, rodei no Windows 10, consegui uma máquina antiga com Windows 7 32bits (lá fiz a comparação), rodei até em Windows Server 2003 R2, em todos os casos não alterou a diferença de velocidade (mudava o seguinte, se o computador for muito veloz, fica proporcionalmente mais veloz, se o computador for lentão, fica proporcionalmente lentão, mas o Clipper em todos os casos foi bem mais rápido...)

Resultado das minhas tentativas: Não ajudou... Alguém já passou por algo assim? Lembra de alguma coisa que eu precisaria me atentar? Alguma dica?

A última possibilidade tem haver com o modo de apresentação do programa, em Clipper o sistema mostra caracteres DOS puro, super econômico nos recursos, no Harbour, uma janela Windows é "emulada", com a aparência original do Clipper - ficou bem parecido (digamos assim para simplificar), pensei que por esta razão, quando está fazendo os cálculos de comissão, fica mostrando um monte de valores que estão sendo calculados na tela e esta "atualização" de milhares de números calculados poderia ser a razão do aumento no consumo de tempo? Seria essa uma possível razão? Achei que poderia ser... alguém já viu isso?

Eu não queria ficar analisando o código legado... tentar reprogramar para otimizar... parece inviável para o caso, então sendo que o mesmo código que funciona no Clipper não deveria ficar no mínimo igual, em termos de velocidade, no Harbour? Compilei em 32 e em 64 bits, não melhorou nada.

Pois é... eu descobri uma coisa... compilando em GTWIN (ou sem GT, deixando padrão), o código ficou igual ao Clipper em aparência e velocidade (igualzinho).
Agora, mudou a GT para qualquer coisinha um pouco melhor, pronto, já ficou 30% mais lento em média... fiquei surpreso com isso!

Essa acabou sendo a solução!

Confesso que fiquei triste que tentar melhorar um pouco a aparência, dando uns recursos extras mínimos, deixa mais lento em virtude de atualização de informação na tela... Mas talvez alguém tenha alguma dica de como conseguir consciliar as duas coisas.

[JoséQuintas]

console é console, GUI é GUI, Windows é Windows.

Baseado nos seus testes, dá a impressão de que GUI/Windows atrapalha, ou vice-versa

Teste 1: Inkey()

Teste 2: Inkey() executado em intervalo de tempo

Explicação:

Não adianta o programa ser ultra-rápido, porque parte do trabalho é feito pelo Windows.
Se o programa usar o tempo máximo, o Windows não tem tempo de fazer o resto.
O tempo precisa ser dividido, e Inkey() é uma das opções.

No console nem tanto, porque o Windows já deve limitar o tempo pra console.
Mesmo assim, pra Clipper existia OSLIB e outros, justamente por conta disso.
Era normal ver programa Clipper usando 100% de CPU e deixando tudo lento.

Vai ter que fazer seus próprios testes pra confirmar sobre isso.
Nos tempos do Clipper eu usava OSLIB, e conseguia reduzir pra ZERO %, aonde sem ela ficava em 100%.
É sério: o programa Clipper PARADO, aparentemente sem fazer nada, consumia 100% de CPU.
Imagine que o Windows precisa tempo pra acessar arquivos, bloquear registros, principalmente em rede, além das outras coisas que o Windows já faz, talvez até mesmo pra atualizar o cache de disco.

O Harbour é mais rápido que o Clipper ?
Talvez por esse motivo possa deixar o Windows mais lento do que o Clipper deixaria, fazer o que...
E em GUI... entra também atualização de tela pelo Windows, querendo ou não.
Se o processamento tem saída em tela... piorou...

[developer]

É um assunto interessante, mas fiz os meus testes e confirmo o resultado:

O Clipper em geral é ligeiramente mais lento, tem uma tonelada de desvantagens, problemas e bugs não resolvidos, uma engenharia não adequada (por isso teve que usar a OSLIB), além de não rodar em 64 bits, e um monte de recursos inexistentes.

Já o Harbour, usando um modo de "texto" (GTWVG/GTWVT) com recursos incríveis do Windows e uma série de vantagens e possibilidades, tem um porém... em uma rotina de impressão na tela que fica atualizando "zilhares" de vezes por minuto (ou segundo), fica notavelmente mais lento.

Exemplo:

Código: Selecionar todos

dbGoTop()
DO  WHILE !EOF()
      // Processamento qualquer...
     @ MAXROW(), 00 SAY FIELD->CODIGO   // Aqui é onde está o gargalo!
ENDDO

O que acontece:

Clipper: Uma letra já é um byte e fica muito pouca informação para atualizar na janela que é TEXTO, então fica super rápido fazer isso.

Harbour: Uma letra é um "desenho" com vários pixels, então tem muito mais informação para atualizar na janela que é GRÁFICA, então fica lento.

Bem, estas são minhas conclusões...

[JoséQuintas]

Junte a isso que em Windows não existe um caractere.
Tudo são sempre janelas.
A janela do aplicativo, supondo 1024x768, são quase 1 milhão de pixels pra serem atualizados.
Nisso entra o que eu falei, o Windows faz coisas, e o aplicativo precisa permitir que o Windows faça seu trabalho.
Justamente por isso tela GUI usa telas menores para as outras coisas, pra que a atualização de tela possa ser dividida em blocos.
E também por isso as placas de vídeo tem cada vez mais gigabytes de capacidade.

Seria substituir isso de ficar mostrando texto, por um gráfico, e mesmo assim não atualizar o tempo todo.
Exemplo que uso: atualizar a cada 1 segundo

Código: Selecionar todos

GrafTempo( nAtual, nTotal )

STATIC FUNCTION GrafTempo( nAtual, nTotal )
   LOCAL cTimeAtu
   STATIC cTimeAnt := ""

   cTimeAtu := Time()
   IF cTimeAtu == cTimeAnt()
      RETURN Nil
   ENDIF
   cTimeAnt := cTimeAtu
   @ MaxRow(), 0 SAY Replicate( "X", nAtual / nTotal * 100 )
   RETURN Nil

Saber o posicionamento a cada 1 segundo é suficiente pra visualizar o tempo.
Nesse 1 segundo, pode ter visto já milhares de registros, deixou de fazer milhares de atualizações de tela.
Atualizar tela é o que leva mais tempo.
Se for jogo então... vixe...