Sistema lento na arquitetura NT

[kiko]

Bom dia, forum.

sei que é uma questao que ja foi debatida centenas de vezes neste forum, porem ainda nao obtive resultados satisfatorios para diminuir o uso do CPU nos meus sistemas em clipper. bom, vamos lá...

com o sistema compilado sem nenhum utilitario, o uso de cpu fica em 100%, tanto em windows xp quanto em 2000

encontrei aqui no forum e em buscas na internet alguns utilitarios para diminuir o uso de cpu. encontrei o TimeSlic, encontrei tb uma função da OsLib, e um terceiro utilitario, chamado DosIdle. testei os 3 utilitarios, porem o uso de cpu continuou em 100%. removi do meu arquivo de linkagem as libs que eram desnecessarias, mas o problema continua.

isso pode ser alguma configuracao do windows? alguma configuracao do cmd.exe que possa ajudar os utilitarios a liberarem o uso de cpu?
obrigado e ate a proxima.

[sygecom]

Eu uso o TIMESLIC....e chamo ele no INICO de cada sistema meu com o comando FREETSLICE(20)...apartir que comecei a usar essa função em meus sistemas eles liberam até 60 % do uso da CPU isso quando o mesmo esta inativo..ou seja...se o meu sistema esta somente aberto e não em uso ele libera caso contrario ele aumenta o uso. talvez vc estaja com algum outro aplicativo carregando sua maquina..já testou em outras maquinas ?

[alaminojunior]

Realmente, usando a TimeSlice, o consumo cai um pouco. Porém ....
Poste para nós como vc usa a TimeSlice.

[Maligno]

isso pode ser alguma configuracao do windows? alguma configuracao do cmd.exe que possa ajudar os utilitarios a liberarem o uso de cpu?

Note que não é apenas o programa Clipper que come tempo de CPU. Se você deixá-lo parado, sem qualquer uso, com FreeTSlice() o consumo de CPU vai a casa dos 5% ou menos. Entretanto, se você estiver com algum programa (ou serviço oculto) do Windows com uma taxa de processamento elevada, o consumo vai subir, naturalmente. Um exemplo: tocadores de MP3. Em condições normais, consomem pouco tempo de CPU. Mas basta ativar algum plug-in gráfico, com algum efeito especial, e o consumo sobe aos 100% facilmente. Nestes casos, qualquer programa, seja DOS ou Windows, ficará prejudicado.

Uma dica para saber pra onde está indo seu processamento é você abrir o Gerenciador de Tarefas e ordenar o grid pelo consumo de CPU, em ordem descrescente. Assim, os maiores comilões de CPU ficarão bem evidentes. Aliás, pode muito bem ser um serviço qualquer do NT. Já viu a lista de serviços? Pelo tamanho, é de dar medo.

[]'s
Maligno
http://www.buzinello.com/prg

[kiko]

ola

Poste para nós como vc usa a TimeSlice.

eu link o obj da timeslic, e no fonte principal, chamo a funcao FREETSLICE(),
sem parametros
mesmo assim o consumo de cpu fica em 100%

Note que não é apenas o programa Clipper que come tempo de CPU

realmente notei isso, maligno. nao apenas programas em clipper comem a CPU pela perna, o proprio edit do ms dos consome 100% de cpu aqui tambem...

Uma dica para saber pra onde está indo seu processamento é você abrir o Gerenciador de Tarefas e ordenar o grid pelo consumo de CPU, em ordem descrescente. Assim, os maiores comilões de CPU ficarão bem evidentes

fiz isso que vc indicou tambem. a maior taxa de consumo de CPU ficou com o NTVDM, tanto com meu sistema em clipper como em qualquer outro aplicativo ms dos...nem o browser firefox, que estou usando pra escrever essa mensagem no topico, consumiu tanto quanto o dos com algum aplicativo carregado...

bom, ainda estou no aguardo...se alguem souber mais algo q possa ser feito, agradeço...ate a proxima

[alaminojunior]

Pessoalmente uso FreeTSlice(20), e resolve.
Tente acrescentar isso

[Stanis Luksys]

Olá,


Acredito que para Clipper uma boa solução é utilizar o Blinker 7.0.

O Blinker disponibiliza a função BLICPUREL(), que vc deve colocar no inicio de seu PRG, dessa forma o problema de processamento será resolvido por completo. Sem o uso de libs ou objs externos.



Falou.

[kiko]

Pessoalmente uso FreeTSlice(20), e resolve.
Tente acrescentar isso

ja usei e nao adiantou nada, infelizmente.....

O Blinker disponibiliza a função BLICPUREL()

ja utilizo o blinker 7.0, porem nao conhecia essa funcao dele...
fiz o teste com ela, agora sim liberou um pouco do uso da cpu...caiu para 30%
vou estudar mais a fundo e ver como posso diminuir ainda mais esse uso da cpu.
obrigado pela atencao de todos e ate a proxima....

[Stanis Luksys]

Só complementando,

Isso acontece pelo fato de o MS-DOS ser emulado, sei que isso não é novidade, mas o que acontece então é que o famoso "prompt do ms-dos" não passa de um emulador, e isso fica evidente qdo você ao abrir qualquer aplicação, mesmo que por um link, o servicço fica descrito como "NTVDM", que é o próprio.

Pois bem, sem querer ser chato, alias já me acostumei a ouvir coisas do tipo "este é um forum de clipper!!", mas insisto. Procute informações sobre a possibilidade de compilar seu programa com xHarbour, se você não faz uso de muitas bibliotecas terceiros, este processo pode ser um tanto simples, e elimina de uma vez por todas este problema, além de agregar recursos, que pode usar caso queira futuramente.

Um bom exemplo da importância de ter seu aplicativo portado para plataforma de 32bits, é que um "programa.exe" fazendo uma rotina pesada de indexação de 10 ou 20 minutos aparecrá no seu gerenciador de tarefas como "programa", e consumindo na casa de 3 ou 4% de CPU, obviamente dependendo da sua capacidade de processamento.

Fica aí registrada a dica, pense no caso.

[Maligno]

Isso acontece pelo fato de o MS-DOS ser emulado

Isso não tem relação com o fato da máquina DOS ser emulada. Meus programas, em repouso, nos Windows 95/98/Me/NT/2K/XP têm taxa de consumo de CPU na casa dos 2 a 5%, usando FreeTSlice(). O problema do colega é outro, com certeza.

para plataforma de 32bits, é que um "programa.exe" fazendo uma rotina pesada de indexação de 10 ou 20 minutos aparecrá no seu gerenciador de tarefas como "programa", e consumindo na casa de 3 ou 4% de CPU, obviamente dependendo da sua capacidade de processamento.

Discordo de novo. Qualquer programa, windows 32 bits ou não, fazendo indexação, consumirá um bom pedaço do tempo de CPU. No que pese o fato do acesso a disco ser mais exigido, que se use DMA, etc..., código precisa ser processado e, logicamente, a CPU tem que trabalhar. Um simples arrastar de mouse já causa picos de mais de 10%, pela quantidade de eventos disparados. Que dizer de um algoritmo de indexação, onde muito mais código é executado? A NÃO SER que você esteja falando de uma arquitetura cliente/servidor, onde o trabalho de indexação é feito pelo servidor e não pela máquina cliente. Se for isso, seu argumento perde completamente o sentido. )

[]'s
Maligno
http://www.buzinello.com/prg

[Maligno]

nao adiantou nada, infelizmente.....

Observe que, se o consumo de CPU não se encontra em algum outro programa, pode ser que, mesmo usando algum artifício para liberar a CPU, seu programa Clipper esteja executando alguma coisa, mesmo em estado de espera. Você tem algum tipo de relógio com algum tipo de verificação, como agendas, por exemplo? Seu programa é texto ou usa alguma LIB gráfica? Existe possibilidade de haver algo sendo executado em background, que você tenha se esquecido de mencionar?

[]'s
Maligno
http://www.buzinello.com/prg

[kiko]

bom dia

como diria jack, the ripper, vamos por partes

quanto a compilar meu sistema em xHarbour, eu penso nessa possibilidde...até ja consegui converter alguns sistemas mais simples, mas, como uso muitas libs externas e a maioria ainda nao esta portada para 32 bits, fica mais complicado. sei que existem muitas ide's graficas para fazer um novo visual no sistema e tudo mais, mas o problema eh tempo para fazer tal coisa, já que aqui eu sou empregado, preciso seguir normas e cumprir metas, entao fica extremamente dificil fazer tal migração no sistema...

quanto a alguma rotina sendo executada em segundo plano, realmente existe, uso no meu sistema a visual lib, ela possui uma funcao, VlScrSaver(), que eu uso pra ativar a protecao de tela do proprio sistema. utilizo tambem a funcao ShowTime(), da Clipper Tools, para exibir um relogio no canto superior do sistema. realmente, depois que removi essas funcoes, o consumo da cpu diminuiu bastante, tanto com a funcao do blinker BLICPUREL() quanto sem ela. ainda nao testei com as funcoes TimeSlic() e DosIdle(), mas ja diminuiu bastante, posso dizer que agora, o desempenho do sistema em xp esta satisfatorio...

obrigado pela ajuda de todos e até a proxima...

[Stanis Luksys]

Maligno,

O que eu falei está correto, este consumo exagerado de CPU é proveniente sim da emulação que o Windows XP faz do antigo MS-DOS, note que o mesmo programa em Win 98 ou 95 ou Linux roda consumindo menos, em termos de %, mesmo que o processador seja inferior. É obvio que isso depende muito da estrutura com que o programa foi desenvolvido, eu já vi casos com xHarbour em que ocupa também 100% em um simples READ, porém com alguns ajustes no código e SEM a necessidade de objetos de terceiros, este problema é removido, coisa que ainda não vi acontecer no Clipper, se tiver um exemplo me mostre e aceitarei com o maior prazer, inclusive adotando em meus programas em Clipper. Veja bem, se você está feliz utilizando FreeTSlice(), tudo bem, eu também estou feliz sem ela e estamos todos felizes.

Quanto a sua segunda citação, caso queira posso colocar aqui um exemplo com indexação de um unico DBF de 10Mb e um programinha INDEX ON compilado com Clipper e o mesmo com xHarbour. para você avaliar a diferença de 100 para 3%.

Se sua cisma é com xHarbour ok, não use, porém não procure desestinmular o seu uso, visto que é uma ferramenta potente e em fase de crescimento contínuo.

Eu mesmo utilizo outras ferramentas não xBase para desenvolvimento, mas tenho grande apreço pelo xHarbour e as facilidades e funcionalidades que encontrei em seu uso, em especial para migração.


kiko,

Note que no meu post anterior não quis te convencer em nada, e inclusive apontei para o caso de libs de terceiros, o que causa problemas no que se refere a migração. (E veja que a tendência é você estar agregando mais e mais para resolver problemas simples como este de CPU e outros, a menos que obtenha ou escreva os fontes, geralmente em C). No caso da "migração impossível", como por exemplo quem usa LLIBG e outras libs gráficas ou não, ainda existem saídas no proprio Clipper, como estamos apresentando e tenho certeza que outras ainda surgirão para que você resolva seu problema. Eu particularnente uso conforme citei acima com Blinker 7, e funciona bem, mas na verdade acabo meio que preferindo indicar mesmo o win 98 para o usuario final, não obrigatoriamente.


Att,

[Maligno]

O que eu falei está correto, este consumo exagerado de CPU é proveniente sim da emulação que o Windows XP faz do antigo MS-DOS

Continuo discordando, por um motivo muito simples. Para muitos usuários de XP, com o DOS emulado, o consumo exagerado de CPU é perfeitamente resolvido com FreeTSlice() ou BliCPURel(). A exceção fica por conta de um ou outro caso que tem processamento em background. Mas aí é só ajustar a codificação para que tudo fique normal.
Ou seja, DOS emulado ou não, o efeito é o mesmo. E já até disse antes que já tive até a impressão de que o DOS emulado do XP é até mais rápido que o DOS nativo. Agora, se pra você a coisa funciona de forma diferente, sinto muito.

Quanto a sua segunda citação, caso queira posso colocar aqui um exemplo com indexação de um unico DBF de 10Mb e um programinha INDEX ON compilado com Clipper e o mesmo com xHarbour. para você avaliar a diferença de 100 para 3%.

Quero ver isso sim. Passe o link dos fontes, EXEs e DBFs. Não posso acreditar que numa indexação a CPU fique estável em 3%. Indexar sem processar código? Me desculpe, mas pra mim isso não existe.

Se sua cisma é com xHarbour ok, não use, porém não procure desestinmular o seu uso, visto que é uma ferramenta potente e em fase de crescimento contínuo.

Não posso discordar de qualquer coisa feita com XHarbour e já logo pensam que estou fazendo campanha contra? Tenha a santa paciência! Que infantilidade!
Já aviso: se você agora for começar essa cruzada santa de novo, vai ficar falando sozinho. Não vou perder meu tempo com causa perdida.

[]'s
Maligno
http://www.buzinello.com/prg

[Stanis Luksys]

Caro Maligno,

Realizei os testes com um milhão de regitros, com sete campos e indexando por tres campos, e realmente devo admitir que não ficou na casa dos 3 ou 4% conforme eu havia dito, chegando a atingir picos de até 93%, mantendo uma média de 37 a 50.

O que ficou muito evidanciado neste teste foi o tempo, o qual fiz questão de registrar. Aqui, testei num P4, e a rotina executada em xHarbour levou 18 segundos, já em clipper consideraveis 101 segundos (1 minuto e 41 segundos). Diferença total de 83 segundos, ou 560%, como preferir.

Bem, fiz na pressa, e aqui vai os fontes, caso não tenha como compilar com xHarbour, me avise e colocarei o binário temporariamente no meu site pra você baixar e testar o tempo. Alias de qualquer maneira colocarei até o final de domingo.

Código: Selecionar todos

*teste.prg
procedure main()

   local i        
   local aEstrut := {}
   local nTempo  :=  seconds()
   
   cls
   
   aAdd ( aEstrut, { "num1", "n", 7, 0 } )
   aAdd ( aEstrut, { "num2", "n", 7, 0 } )
   aAdd ( aEstrut, { "num3", "n", 7, 0 } )
   aAdd ( aEstrut, { "car1", "c", 7, 0 } )
   aAdd ( aEstrut, { "car2", "c", 7, 0 } )
   aAdd ( aEstrut, { "car3", "c", 7, 0 } )
   aAdd ( aEstrut, { "data", "d", 8, 0 } ) 
   
   ? "Criando arquivo com 7 campos..."
   dbCreate( "arquivo", aEstrut )
   ?? " Ok."
   
   use arquivo
   
   ? "Incluindo um milhão de registros..."
   for i := 1 to 1000000
      
      dbAppend()
      replace  num1 with i ,;
               num2 with i ,;
               num3 with i ,;
               car1 with StrZero( i, 7 ) ,;
               car2 with StrZero( i, 7 ) ,;
               car3 with StrZero( i, 7 ) ,;
               data with Date()
   
   next i
   ?? " Ok."

   ? "Indexado arquivo por 3 campos..."   
   index on ( StrZero( num1 ) + car1 + DToC( data ) ) to indice
   ?? " Ok."
   
   close arquivo
   
   ? "A operacao completa levou " + AllTrim( Str( seconds() - nTempo ) ) + " segundos"
   
   Inkey(0)

   return

Os 3% ao qual me referi, realmente não consegui alcançar, portanto posso aqui afirmar que errei quanto a este numero.

Caso você se sinta a vontade pode também dizer aqui que neste simples caso foi muito relevante o uso do xHarbour, como ferramenta de migração para 32 bits, pois talvez seja importante a comunidade ouvir de uma pessoa experiente e com grandes conhecimentos técnicos como você algo neste sentido.


Ok, agradeço antecipadamente pela atenção, na certeza de que fará juz ao tempo que foi gasto na confecção deste simples exemplo, simplesmente testando.