Garbage Collector, ente con vida propia?

Flaco tienes toda la rason.
Ese tema lo tienes bajo la mesa.Te dejan ver un poco pero
no lo suficiente.
Segun la teoria hay un evento Finalize este evento se
dispara justo antes de que nuestro objeto sea eliminado
de la memoria por el GC.En ese momento el GC de verificar
si tiene un evento Finalize asociado. De ser asi lo pasa
a una lista separada para que se valla ejecutando el
codigo del evento y continua con su proceso normal(sin
eliminar el codugo en memoria.Luego la proxima pasada
elimina definitivamente el objeto que esten pendientes.
(el problema es que tendria que dar 2 pasadas para
liberar los recursos.
Desventajas
1. No sabemos cuando diablos GC se ejecuta solo el CLR
sabe.

2.Si un objeto tiene el evento Finalize tiene que dar 2
pasadas.


Segun entendi en el libro tiene muchas ventas que en vb6
no tiene.No se un diablo de vb6.Pero eso dice el libro. Y
pues por FE lo creo de igual forma por FE hay que confiar
en GC.

Aki unas preguntas para los "EXPERTOS" no hay forma de
entrar al CLR ? el CLR no se puede modificar no hay
eramientas asi como Microsoft .NET Framework 1.1
Configuration.? O hay que esperar que un hacker lo
encuentre la manera para usarlo para jorobar?


Miao...

Parece que el tema del garbage collector en Vb.Net no

esta

muy bien cubierto, tengo 6 libros diferentes y apenas lo
nombran. Desarrollo una aplicacion que practicamente es

un

scada, eso significa muchas imagenes, muchas

animaciones,

muchos datos, muchos controles, mucho espacio en

memoria.

Cuando la aplicacion se levanta se lleva unos 300 megas

y

a medida que se van abriendo pantallas aumenta
peligrosamente. He sido cuidadoso con los recursos, de
hecho antes de abrir una nueva ventana cierro la

anterior

e incluyo un clsForms.AnyForm = Nothing en su Dispose,
siguiendo los consejos de un buen amigo programador,

pero

nada mejora, la memoria sigue igual. Tambien hago una
llamada al GC, pero parece que este trabaja cuando le
viene en gana, pues solo cuando la memoria va por los

550 -

600 es que empieza a liberarse. Se puede confiar en el
GC de VB.Net?
.

Aunque no sepamos cuando se ejecuta lo que si que se puede hacer es forzar
al GC para que se ejecute cuando nosotros lo necesitemos, aunque no es lo
recomendado.

Drk

"DJ_MIAO" escribió en el mensaje
news:6d1c01c475bb$d3d8ee40$

Flaco tienes toda la rason.
Ese tema lo tienes bajo la mesa.Te dejan ver un poco pero
no lo suficiente.
Segun la teoria hay un evento Finalize este evento se
dispara justo antes de que nuestro objeto sea eliminado
de la memoria por el GC.En ese momento el GC de verificar
si tiene un evento Finalize asociado. De ser asi lo pasa
a una lista separada para que se valla ejecutando el
codigo del evento y continua con su proceso normal(sin
eliminar el codugo en memoria.Luego la proxima pasada
elimina definitivamente el objeto que esten pendientes.
(el problema es que tendria que dar 2 pasadas para
liberar los recursos.
Desventajas
1. No sabemos cuando diablos GC se ejecuta solo el CLR
sabe.

2.Si un objeto tiene el evento Finalize tiene que dar 2
pasadas.


Segun entendi en el libro tiene muchas ventas que en vb6
no tiene.No se un diablo de vb6.Pero eso dice el libro. Y
pues por FE lo creo de igual forma por FE hay que confiar
en GC.

Aki unas preguntas para los "EXPERTOS" no hay forma de
entrar al CLR ? el CLR no se puede modificar no hay
eramientas asi como Microsoft .NET Framework 1.1
Configuration.? O hay que esperar que un hacker lo
encuentre la manera para usarlo para jorobar?


Miao...


>Parece que el tema del garbage collector en Vb.Net no
esta
>muy bien cubierto, tengo 6 libros diferentes y apenas lo
>nombran. Desarrollo una aplicacion que practicamente es
un
>scada, eso significa muchas imagenes, muchas
animaciones,
>muchos datos, muchos controles, mucho espacio en
memoria.
>Cuando la aplicacion se levanta se lleva unos 300 megas
y
>a medida que se van abriendo pantallas aumenta
>peligrosamente. He sido cuidadoso con los recursos, de
>hecho antes de abrir una nueva ventana cierro la
anterior
>e incluyo un clsForms.AnyForm = Nothing en su Dispose,
>siguiendo los consejos de un buen amigo programador,
pero
>nada mejora, la memoria sigue igual. Tambien hago una
>llamada al GC, pero parece que este trabaja cuando le
>viene en gana, pues solo cuando la memoria va por los
550 -
> 600 es que empieza a liberarse. Se puede confiar en el
>GC de VB.Net?
>.
>

Hola Javier
mira no soy un experto pero si te puedo decir que he observado, que no
importa cuanta memoria consume tu sistema, por ejemplo en mi equipo tengo
1GB de memoria y al cargar como dices se va a unos 300 MB y sigue
aumentando, pero la aplicacion es igual de eficiente en equipos que tienen
128 MB, lo que yo se es que el GC administra la memoria, pero si estas
teniendo cuidado en liberar tus recursos la verdad yo no me preocuparia por
la memoria.
Por otro lado yo intento no utilizar el evento Finalize, por obvias razones


Saludos

"Drk" escribió en el mensaje
news:

Aunque no sepamos cuando se ejecuta lo que si que se puede hacer es forzar
al GC para que se ejecute cuando nosotros lo necesitemos, aunque no es lo
recomendado.

Drk

"DJ_MIAO" escribió en el mensaje
news:6d1c01c475bb$d3d8ee40$
> Flaco tienes toda la rason.
> Ese tema lo tienes bajo la mesa.Te dejan ver un poco pero
> no lo suficiente.
> Segun la teoria hay un evento Finalize este evento se
> dispara justo antes de que nuestro objeto sea eliminado
> de la memoria por el GC.En ese momento el GC de verificar
> si tiene un evento Finalize asociado. De ser asi lo pasa
> a una lista separada para que se valla ejecutando el
> codigo del evento y continua con su proceso normal(sin
> eliminar el codugo en memoria.Luego la proxima pasada
> elimina definitivamente el objeto que esten pendientes.
> (el problema es que tendria que dar 2 pasadas para
> liberar los recursos.
> Desventajas
> 1. No sabemos cuando diablos GC se ejecuta solo el CLR
> sabe.
>
> 2.Si un objeto tiene el evento Finalize tiene que dar 2
> pasadas.
>
>
> Segun entendi en el libro tiene muchas ventas que en vb6
> no tiene.No se un diablo de vb6.Pero eso dice el libro. Y
> pues por FE lo creo de igual forma por FE hay que confiar
> en GC.
>
> Aki unas preguntas para los "EXPERTOS" no hay forma de
> entrar al CLR ? el CLR no se puede modificar no hay
> eramientas asi como Microsoft .NET Framework 1.1
> Configuration.? O hay que esperar que un hacker lo
> encuentre la manera para usarlo para jorobar?
>
>
> Miao...
>
>
> >Parece que el tema del garbage collector en Vb.Net no
> esta
> >muy bien cubierto, tengo 6 libros diferentes y apenas lo
> >nombran. Desarrollo una aplicacion que practicamente es
> un
> >scada, eso significa muchas imagenes, muchas
> animaciones,
> >muchos datos, muchos controles, mucho espacio en
> memoria.
> >Cuando la aplicacion se levanta se lleva unos 300 megas
> y
> >a medida que se van abriendo pantallas aumenta
> >peligrosamente. He sido cuidadoso con los recursos, de
> >hecho antes de abrir una nueva ventana cierro la
> anterior
> >e incluyo un clsForms.AnyForm = Nothing en su Dispose,
> >siguiendo los consejos de un buen amigo programador,
> pero
> >nada mejora, la memoria sigue igual. Tambien hago una
> >llamada al GC, pero parece que este trabaja cuando le
> >viene en gana, pues solo cuando la memoria va por los
> 550 -
> > 600 es que empieza a liberarse. Se puede confiar en el
> >GC de VB.Net?
> >.
> >

¿A que te refieres con lo del clsForms.AnyForm?.

Asignar nothing no sirve de nada, o solo serviría en casos poco habituales.
Si estás interesado podría explicarte en cuales, pero no quiero enrollarme.
Lo que si es importante es que liberes los recursos IDisposable llamando a
Dispose. En especial imágenes, etc...

Por lo demás, ten en cuenta que el GC solo funciona cuando es necesario.
¿Has probado tu aplicación en un equipo con poca memoria?. ¿Has probado a
cargar tu sistema?. Ten en cuenta que cuanto menos actúe el GC, más
eficiente será la aplicación. Si la memoria no es necesaria, no debería
liberarse hasta el fin de la aplicación.

Juan Carlos Badiola
MVP - C#