Consumo de memória.

[Personal]

O consumo de memoria não esta sendo liberado, quando fecha os módulos.

Vai acumulando.

Alguma solução para isto.

[Ale SB]

Aun dejando que el sistema no libre de la memoria, esto ha sucedido a cualquier pantalla, incluso con un simple MsgInfo ().

¿Cómo resolver esto?

http://img203.imageshack.us/img203/3269/consumomem1.jpg

http://img594.imageshack.us/img594/661/consumomem2.jpg

http://img805.imageshack.us/img805/6095/consumomem3.jpg

http://img534.imageshack.us/img534/1716/consumomem4.jpg

Saluds, Ale

[Personal]

Ainda sem solução.

[MGA]

Ola Sergio,

Estou com 8 clientes reclamando que o sistema depois de um certo tempo de uso fica muito lento.

Notei que o xBrowse consome muita memoria, e estou trocando para TSBROWSE no meu modulo de pedidos que é muito usado na esperança de melhorar esta situação.

Estou usando FWH 10.2

[Ale SB]

Ola Sergio,

Estou com 8 clientes reclamando que o sistema depois de um certo tempo de uso fica muito lento.

Notei que o xBrowse consome muita memoria, e estou trocando para TSBROWSE no meu modulo de pedidos que é muito usado na esperança de melhorar esta situação.

Estou usando FWH 10.2

Amigo, intercambiarán seis por media docena.

El problema se produce en las pantallas de simple.

Saluds, Ale

[Antonio Linares]

Ale, Sergio,

El consumo de memoria se produce generalmente por el uso de recursos de Windows que no se liberan correctamente. En el administrador de tareas de Windows seleccionar que se vean los GDI en uso. Esto os dará una primera pista de la existencia de handles de GDI de Windows sin liberar. Fijaros en los GDI que está usando Chrome aqui:

Una vez se confirma la existencia de esos handles GDI sin liberar, hay que proceder a buscarlos y a solucionar la causa:
http://forums.fivetechsupport.com/viewt ... etresdebug

[Antonio Linares]

Ale,

A parte de lo comentado anteriormente, la Clase TXBrowse tenia errores importantes en su diseño original en relación al consumo de handles GDI. Estos errores se han ido solucionando y en la actualidad ya no los hay.

En el caso de que estés usando una versión no actualizada, esa puede ser perfectamente la causa del consumo de memoria que comentas.

Finalmente añadir que la memoria en Harbour no se libera definitivamente hasta que no se llama a hb_gcAll(), que es cuando se invoca al "recolector de basura" de la maquina virtual de Harbour. FiveWin llama a esta función al salir de una caja de diálogo, pero no lo hace en otras situaciones. Es por esto que si no se llama a ninguna caja de diálogo, hay que llamar a hb_gcAll() de vez en cuando para que se libere la memoria no usada. Tampoco hay que abusar en llamar a esta función pues es un proceso relativamente lento que implica recorrer todos los objetos de memoria que tiene en uso Harbour.

[Raymundo Islas M.]

Antonio,

Este es un tema que me interesa y mucho

En mi caso, que casi no tengo dialogos por abrir/cerrar, ya que todo lo manejo en pestañas de Folders lo mas adecuado seria montar un timer : unas 7 veces por dia seran suficientes ?

Algo similar me pasaba hace no mucho con los recordsets, seguramente algo no estaba haciendo bien pero el asunto es que cada vez que cambiaba de fila, como se disparaba un evento en el on change de un browse para mostrar ciertos datos, me iba consumiendo memoria ( 4 - 8 kb ) pero ya haciendo cuentas al final del dia se hubiera quedado sin recursos la pc, asi que probando y rastreando en que momento/lugar sucedia me di cuenta que era al generar el RS, asi que al usar el GetRows() y manejar los datos en array no generaba ningun incremento.

Saludos

[Antonio Linares]

Raymundo,

En vez de plantear el llamar a hb_gcAll() un número x de veces, seria preferible llamarle cuando la memoria sobrepase un determinado valor, pues depende de la cantidad de trabajo que este haciendo el programa, ó de cuanto se esté usando.

Otra opción sería que cada x veces que se llame a una opcion del programa, se llame a hb_gcAll(). Tampoco es necesario usar un timer. Por ejemplo, despues de realizar un proceso que implique usar bastante memoria, llamar a hb_gcAll() está bien.

Lo que no hay que hacer es estar llamándolo a cada instante

[Raymundo Islas M.]

Antonio,

Ok, entendido y anotado !

Tal y como se dice por aca : Ni tanto que queme al Santo, ni tanto que ni lo alumbre !

De hecho, creo que solo me falta checar al momento de mostrar/cambiar alguna imagen de los items, ahi es donde veo que todavia me incrementa, recuerdo haber leido algun post con una lineas para "tumbar" los handles u objetos de la memoria, deja lo busco para aplicarlo, si tu lo recuerdas te agradeceria el link.


Saludos y Gracias

[Antonio Linares]

Raymundo,

http://forums.fivetechsupport.com/viewt ... etresdebug