Enviado: 22 Fev 2008 01:55
Veja que Windows 98 existe em duas versões diferentes. Não lembro qual eu usava até a época em que mudei pro XP, mas sofri esse problema. Talvez em alguma versão o problema não se fazia notar facilmente. Se bem me lembro, no Windows 98 esse problema era realmente um pouco mais suave. Mas existia.
Leve em conta que a última versão da OSLib foi lançada em 98, quando era muito difícil encontrar o Windows NT em empresas pequenas. Aliás, aqui em Londrina nunca vi alguém usando o NT. Kernel NT mesmo só a partir de (+/-) 2002 com o Windows 2000. E a OsLIB tem uma função exatamente pra resolver essa lentidão, embora em algumas ocasiões ela não tenha funcionado pra mim.
Agora, o problema do Clipper que faz surgir essa lentidão está na forma como é feita a coleta de lixo, desfragmentação, etc. O manipulador de teclado, nos momentos de ociosidade do sistema, aproveita(ria) pra rodar o garbage collector, que não funciona como deveria. A idéia da FreeTSlice() é justamente fazer um gancho nesse manipulador e, no período de ociosidade, liberar o processador, emitindo uma interrupção de tempos em tempos. Daí a necessidade daquele delay. Então o processador volta a um nível mais aceitável de consumo, em repouso, na casa dos 2% ou menos ainda.
Inclusive, vale a nota: quem usa um artifício desses pra reduzir o consumo de CPU, deve ficar atento para acionar manualmente a coleta de lixo, já que o automático passa a ficar desligado. Faz-se isso com chamadas à função Memory(-1) em pontos estratégicos, como: retorno de funções que alocam matrizes, fechamento de arquivos e na saída de qualquer ponto em que houver um descarte de memória. Sem isso a fragmentação vai aumentar até o ponto de começar a ser feito swap em disco. Daí, lentidão de novo. A coisa fica minimizada em programas que utilizam o modo protegido, claro. Mas ainda assim, o swap é uma possibilidade.
Há tempos venho pensando em modificar a FreeTSlice() pra invocar a coleta de lixo de forma automática, pra que tudo fique como antes. Falta tempo pra mexer nisso. :[
Leve em conta que a última versão da OSLib foi lançada em 98, quando era muito difícil encontrar o Windows NT em empresas pequenas. Aliás, aqui em Londrina nunca vi alguém usando o NT. Kernel NT mesmo só a partir de (+/-) 2002 com o Windows 2000. E a OsLIB tem uma função exatamente pra resolver essa lentidão, embora em algumas ocasiões ela não tenha funcionado pra mim.
Agora, o problema do Clipper que faz surgir essa lentidão está na forma como é feita a coleta de lixo, desfragmentação, etc. O manipulador de teclado, nos momentos de ociosidade do sistema, aproveita(ria) pra rodar o garbage collector, que não funciona como deveria. A idéia da FreeTSlice() é justamente fazer um gancho nesse manipulador e, no período de ociosidade, liberar o processador, emitindo uma interrupção de tempos em tempos. Daí a necessidade daquele delay. Então o processador volta a um nível mais aceitável de consumo, em repouso, na casa dos 2% ou menos ainda.
Inclusive, vale a nota: quem usa um artifício desses pra reduzir o consumo de CPU, deve ficar atento para acionar manualmente a coleta de lixo, já que o automático passa a ficar desligado. Faz-se isso com chamadas à função Memory(-1) em pontos estratégicos, como: retorno de funções que alocam matrizes, fechamento de arquivos e na saída de qualquer ponto em que houver um descarte de memória. Sem isso a fragmentação vai aumentar até o ponto de começar a ser feito swap em disco. Daí, lentidão de novo. A coisa fica minimizada em programas que utilizam o modo protegido, claro. Mas ainda assim, o swap é uma possibilidade.
Há tempos venho pensando em modificar a FreeTSlice() pra invocar a coleta de lixo de forma automática, pra que tudo fique como antes. Falta tempo pra mexer nisso. :[