Problema grave de velocidad

[jmartial]

Hola,

Estoy teniendo unos problemas de lentitud de la aplicación conforme se usa en el tiempo, pero más bien parece que la pocket en sí se cada vez va más lenta, hasta que se cuelga en cualquier proceso de la aplicación fwppc y hay que resetearla.

Investigando, para descartar cosas que pudieran ser, me gustaría usar sólo las librerias necesarias para compilar. Pero veo demasiadas, Antonio estas son las que uso, dime cuales no me sirven para nada por favor.

coredll.lib
corelibc.lib
aygshell.lib
ceshell.lib
ws2.lib
mfcc400.lib ??
ole32.lib ??
commctrl.lib
wininet.lib


Aparte de las normales de Harbour.

Un Saludo,
Joaquín

[Antonio Linares]

Joaquín,

Las librerías no tienen por qué ser un problema. Puedes ir quitando una a una y verás las que te pide FWPPC.

Pudiera tratarse de un problema de recursos. En caso de que estés usando bitmaps, brushes, fonts, etc. te has asegurado de destruirlos correctamente ?

[jmartial]

Antonio,

Estoy casi seguro de que no tiene que ver con que no libere recursos como bitmaps, font, etc.

Uso el api de winninet y ocurre sólo con Windows CE no con mobile.

¿Tengo alguna forma de comprobar si estoy perdiendo, recursos ? ¿se verá en la memoria libre? ¿Como le podría poner una traza?

Es un problema de los desconcertantes y que además no sabes por donde buscar. La aplicación después del día completo de trabajo, ni da GPF´s ni salta ningún error, nada.

Otra cosa es que abro todas las DBF´s al iniciar y las cierro al terminar, aunque en estas maquinitas, la gente suele dejar el programa días y días abierto. ¿Podría ser problema con el rdd de HB ? Uso cdx´s


Un Saludo y gracias,
Joaquín

[Antonio Linares]

Joaquín,

Usas alguna caja de diálogo en tu aplicación ?

La llamada al recolector de basuras de Harbour la hacemos al salir de una caja de diálogo. Una aplicación que no usase diálogos, no estaría llamando nunca al recolector de basuras.

En ese caso habría que hacer una llamada a hb_gcAll() de vez en cuando.

[jmartial]

Antonio,

Uso una Windows principal, y todo lo demás son cajas de diálogos.


Un Saludo y gracias,
Joaquín

[Antonio Linares]

Joaquín,

Entonces no es el recolector de basuras de Harbour.

Has mirado la memoria libre del sistema en el Pocket PC, para ver si está disminuyendo ?

[jmartial]

Antonio,

esa era una de las cuestiones, ¿como miro en fwppc la memoria libre en la pocket?

Existe alguna función o necesito llamar al api de windows ce?


Un Saludo,
Joaquín

[Antonio Linares]

Joaquín,

Settings -> System -> Memory

[jmartial]

Antonio,

Eso sí lo sabía, la idea era que mi aplicación pudiera obtener ese valor e ir guardando un log file con una traza y que memoria iba quedando en cada caso, y después de más de una hora de usar la aplicación, mirar este fichero para ver en qué casos disminuye la memoria.


Un Saludo,
Joaquín

[Antonio Linares]

Joaquín,

VOID GlobalMemoryStatus(
LPMEMORYSTATUS lpBuffer // pointer to the memory status structure
);

No está implementada en FWPPC. Tienes que implementarla con #pragma BEGINDUMP ó desde un fichero en C.

[jmartial]

Antonio,

He hecho un logfile con la memoria cuando se entra y sale de un diálogo, con y sin añadir hb_gcall (da el mismo resultado) y lo más preocupante
es que un diálogo con 1 checkbox 1 combo 1 browse y 2 botones aceptar/cancelar después de entrar y salir (sin hacer nada) 5 veces pierde 1.4 Mb de memoria física disponible (Estoy probando en windows CE 5.0)

Si me pudieras iluminar para saber que método uso para descubrir que se está quedando en memoria, te lo agradecería.

No sé que probar más, llevamos unos 8 años con fw y conocemos bastante bien el tema de no dejar, brush, fonts y demás sin destruir.


Decirte, por si tiene algo que ver, que creamos varios fonts para toda la aplicación al principio, y los destruímos al salir de la misma. Para no estar creando y destruyendo fonts continuamente.


Un Saludo,
Joaquín

[Antonio Linares]

Joaquín,

> Estoy probando en windows CE 5.0

Puedes probarlo en el emulador ó en Windows Mobile ?

[jmartial]

Antonio,

He hecho exactamente lo mismo en windows mobile, y también pierde memoria con sólo entrar y salir de cualquier diálogo de la aplicación.

No obstante, parece ser que no tanta cantidad.

Te puedo decir que clientes que durante el día han estado usándolo, se les ha ido poniendo cada vez más lenta la PDA y en algunos casos se ha bloqueado sin memoria.

He entrado y salido en diálogos 5 veces y me ha perdido 1.3 Mb.

Todo son diálogos menos la windows principal,

Si hubiera por ahí alguna función que me chequee que recurso es el que se queda en memoria, sería lo ideal. O forma de construírmela.

Un Saludo,
Joaquín

[jmartial]

Antonio,

Indagando tengo una duda. En la ventana principal tengo un bitmap de fondo que defino así:


DEFINE BITMAP p:oBmpPrinc RESOURCE "FONDO" OF oWnd

y para el refresco:
oWnd:bPainted := { |hDC,cPs,oWnd| oWnd:SayBitmap( 0, 0, p:oBmpPrinc )}


¿Perderá el método SayBitmap recursos en la pocket? ¿O es incorrecta esta forma de proceder para pintar el fondo de la ventana para la pocket?

A lo mejor no es al salir de los diálogos cuando pierde recursos, sino cuando repinta el bitmap.

Un Saludo,
Joaquín

[Antonio Linares]

Joaquín,

Prueba a quitar esta línea de tu aplicación y prueba de nuevo:

// oWnd:bPainted := { |hDC,cPs,oWnd| oWnd:SayBitmap( 0, 0, p:oBmpPrinc )}