What good is this automatic garbage collector?

[joe]

I have a simple .NET application with two or three listViews which are
filled with icons and when the user click on the proper item, they display
the related images. I use "image = null ; " for all images that have been
used and are going to be closed. This is how ever no way to reduce the
memory consumption. I have noticed , using the task manager, that garbage
collector doesn't actually do any collections unless the computer becomes
low on memory. This is very foolish, and what good is a garbage collector
which doesn't collect the disposed objects when they aren't needed anymore?

Besides, calling CG.Collect() is usually avoided for performance and speed.
What else can i do?

PS: i wont hurt you to read this:
http://www.cs.tut.fi/~warp/MicrosoftComparingLanguages/

[Cor Ligthert]

>I have noticed , using the task manager, that garbage

collector doesn't actually do any collections unless the computer becomes
low on memory. This is very foolish, and what good is a garbage collector
which doesn't collect the disposed objects when they aren't needed
anymore?

Allthough it the task manager is not the good instrument to check.

I am curious, what is foolish about this, every garbaging uses processor
time.

To use a methpore "Do you empty your trash bin, everytime you have thrown in
a paper or whatever?

Cor

[Patrice]

Have you tried to call Dispose ?

Though the point of a garbage collector is that there is no need to reclaim
memory if you have no use for it, it's worth to keep in mind that it have
its root in the managed world and that the Dispose or Close methods should
still allows to reclaim unmanaged memory immediately...

Please let us know...

Patrice

--

"joe" <jo*****@rot.of m.net> a écrit dans le message de
news:uE******** ********@TK2MSF TNGP14.phx.gbl. ..

I have a simple .NET application with two or three listViews which are
filled with icons and when the user click on the proper item, they display
the related images. I use "image = null ; " for all images that have been
used and are going to be closed. This is how ever no way to reduce the
memory consumption. I have noticed , using the task manager, that garbage
collector doesn't actually do any collections unless the computer becomes
low on memory. This is very foolish, and what good is a garbage collector
which doesn't collect the disposed objects when they aren't needed anymore?
Besides, calling CG.Collect() is usually avoided for performance and speed. What else can i do?

PS: i wont hurt you to read this:
http://www.cs.tut.fi/~warp/MicrosoftComparingLanguages/

[joe]

> To use a methpore "Do you empty your trash bin, everytime you have thrown

in a paper or whatever?

Can you recycle disposed objects in a programming language? If you can, then
why do you put them in the recycle bin?
just curious.

[joe]

"Patrice" <no****@nowhere .com> wrote in message
news:eZ******** *****@TK2MSFTNG P15.phx.gbl...

Have you tried to call Dispose ?
Dispose is not supported on all objects. In my case, calling GC.collect()
does a little help though.
Though the point of a garbage collector is that there is no need to
reclaim
memory if you have no use for it, it's worth to keep in mind that it have
its root in the managed world and that the Dispose or Close methods should
still allows to reclaim unmanaged memory immediately...

Yes, in a perfect managed world where no one wants to struggle with memory
allocation and release, this could be good suggestion. But in the same
managed world there are times when an object is used only "once", and then
thrown away forever or used after a long time or maybe in next program
launch. Why should its memory be still occupied by the program?
I mean, there should a way to have more control over this kind of memory
management. ( sth like a half-automatic GC, until the day GC becomes really
smart and intelligence)

i can also use SetProcessWorki ngSetSize(-1,-1) , however it is not usually
recommended.

[Olaf Baeyens]

> I have noticed , using the task manager, that garbage

collector doesn't actually do any collections unless the computer becomes
low on memory. This is very foolish, and what good is a garbage collector
which doesn't collect the disposed objects when they aren't needed anymore?

Why is this foolish? Why would the GC need to use additional processing
power for dynamic cleanup?
What would the unused memory be needed for untill the system gets low on
memory?

I like the way it is implemented. It only cleans up when new memory is
needed and when there is no memory left.
This way the GC is faster, because it can do the job in one go, and your
code gets executed faster because it does not lose time to clean up every
time you release memory. and once it starts cleaning up, it can do it
faster.

The only anoying thing that could give problems is for games, that generates
a hickup because one GC takes up a little longer than a dynamic one, but
overall, a GC only during low memory will actually free up more processing
power. And I believe that it also speeds up your program since the compiled
code is smaller for that function (no code for cleanup in that function) and
thus the chance that this function could reside completely in your processor
cache could speed up dramatically.

One thing that might be implemented is to use dynamic GC when the processor
is in idle mode. But then again, you could regard this as unecesary using
processor cycles, which decreases the laptop batterie power because it needs
more power.

[Brian Gideon]

joe wrote:

[snip]

PS: i wont hurt you to read this:
http://www.cs.tut.fi/~warp/MicrosoftComparingLanguages/

I disagree. While some aspects of the article may be at least
partially correct, it does more harm than good. For example, the
author completely missed the point of the original claim about reduced
memory leaks. Similarly, I thought the other points were
misinterpreted as well, albiet, to a lesser degree.

Brian

[Patrice]

If "Dispose" is not supported you should have then only the managed object.
In most cases it shouldn't a problem (ie. the bitmap portion of an image
object is likely much more big than the members of the managed class).

Another option I can think of is for example for voluminous data structure
to change the current size (for example resizing an array to a lower size).
Could perhaps help (not sure, give this a try, let us know please).

On the other hand what is the problem with having something kept around and
that doesn't harm ? If you really want to clean up the object immediately
they would have to be back to reference counting...

For now I would start first to see if it raises an actual problem and
wouldn't bother if not...

Patrice

--

"joe" <jo*****@rot.of m.net> a écrit dans le message de
news:ub******** ******@tk2msftn gp13.phx.gbl...

"Patrice" <no****@nowhere .com> wrote in message
news:eZ******** *****@TK2MSFTNG P15.phx.gbl...

Have you tried to call Dispose ?
Dispose is not supported on all objects. In my case, calling GC.collect()
does a little help though.

Though the point of a garbage collector is that there is no need to
reclaim
memory if you have no use for it, it's worth to keep in mind that it have its root in the managed world and that the Dispose or Close methods should still allows to reclaim unmanaged memory immediately...

Yes, in a perfect managed world where no one wants to struggle with memory
allocation and release, this could be good suggestion. But in the same
managed world there are times when an object is used only "once", and then
thrown away forever or used after a long time or maybe in next program
launch. Why should its memory be still occupied by the program?
I mean, there should a way to have more control over this kind of memory
management. ( sth like a half-automatic GC, until the day GC becomes

really smart and intelligence)

i can also use SetProcessWorki ngSetSize(-1,-1) , however it is not usually
recommended.

[Nick Malik [Microsoft]]

PS: i wont hurt you to read this:
http://www.cs.tut.fi/~warp/MicrosoftComparingLanguages/

This commentary is a case of one inexperienced programmer criticizing a
feature that they do not understand, with poor understanding of the forces
that underlie the fundamental reasoning. Garbage collection is easy in
C++... if every developer were free of mistakes and if code were not
complex. This is not the case in the real world. The author of that
article completely failed to recognize the reality of memory leaks in a
production system of substantial size.

One reason for the success of BOTH Java and .Net languages like C# is that
this problem is solved for you. You may not agree with the way in which it
is solved, but it is solved for you. That is a huge step up and a major
boon for software development.

The problem isn't the computers or their languages... it is the limitations
of the humans who use them.
--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
"joe" <jo*****@rot.of m.net> wrote in message
news:uE******** ********@TK2MSF TNGP14.phx.gbl. ..I have a simple .NET application with two or three listViews which are
filled with icons and when the user click on the proper item, they display
the related images. I use "image = null ; " for all images that have been
used and are going to be closed. This is how ever no way to reduce the
memory consumption. I have noticed , using the task manager, that garbage
collector doesn't actually do any collections unless the computer becomes
low on memory. This is very foolish, and what good is a garbage collector
which doesn't collect the disposed objects when they aren't needed
anymore?

Besides, calling CG.Collect() is usually avoided for performance and
speed.
What else can i do?

PS: i wont hurt you to read this:
http://www.cs.tut.fi/~warp/MicrosoftComparingLanguages/

[joe]

Nick,
Your reasoning is respected and welcomed. I don't hate or love something
like idiots, i simply point out the weak points.

It is true that CG is a great miracle in C# and java, and help the
programmer to concentrate on more critical aspects of his work, however,
when it comes to page faults, it exhibits its weak points.

You might say that because allocation or garbage collection is done only
when the computer becomes low on memory, you gain much higher performance in
your application. This can be true for small programs, however, when some
real big programs are executed on computers with low memory ( sth like 256
MB) , then the amount of OS's page swapping and virtual memory reading and
writing really slows down the entire system. Just think, why your OS is much
faster after a clean restart than the time it is run for long hours of
application executing and playing with the virtual memory?

Well, at least there could be stricter algorithm implemented, which would
force the GC to come into play much sooner that it does now on low-memory
PCs.
"Nick Malik [Microsoft]" <ni*******@hotm ail.nospam.com> wrote in message
news:pI******** ************@co mcast.com...

PS: i wont hurt you to read this:
http://www.cs.tut.fi/~warp/MicrosoftComparingLanguages/

This commentary is a case of one inexperienced programmer criticizing a
feature that they do not understand, with poor understanding of the forces
that underlie the fundamental reasoning. Garbage collection is easy in
C++... if every developer were free of mistakes and if code were not
complex. This is not the case in the real world. The author of that
article completely failed to recognize the reality of memory leaks in a
production system of substantial size.

One reason for the success of BOTH Java and .Net languages like C# is that
this problem is solved for you. You may not agree with the way in which
it is solved, but it is solved for you. That is a huge step up and a
major boon for software development.

The problem isn't the computers or their languages... it is the
limitations of the humans who use them.
--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.