ExamGuru IT/.Net Guru : Setting objects to Nothing uses less memory! on microsoft.public.dotnet.framework.performance

.NETGURU

Setting objects to Nothing uses less memory!

Messages

Related Types

This message was discovered on microsoft.public.dotnet.framework.performance.
Responses highlighted in red are from those people who are likely to be able to contribute good, authoratitive information to this discussion. They include Microsoft employees, MVP's and others who IMHO contribute well to these kinds of discussions.

Post a new message to this list...

vdex42@hotmail.com

Hi Chris,

Thanks for replying.

Do I understand correctly:

When the system reaches the end of the function that doesn't do the set
object to nothing: The garbage collector only does one pass and frees
"bigObjects", but does not recursively free anything it owns? (i.e.
that only happens in the second pass)

But when the system reaches then end of the function that sets
everything to nothing at the end: The garbage collector frees
"bigObjects" and its internal instance of "lotsOfData" in the first
pass , because I have explicitly forced the internal references to be
lost with my "InternalSetNull" function?

Thanks,
Ivan

"Chris Lyon [MSFT]" wrote:
[Original message clipped]

release memory sooner. In your code
> snippets, you're demonstrating a good example of when to set things
to null/Nothing, but maybe not how you expected.
[Original message clipped]

references to lotsOfData. By setting
> lotsOfData to null, you're telling the GC that you no longer need it,
but you still want to keep around your ReallyBigObjects. The GC will
then collect the lotsOfData arrays when it
> performs its next collection, but not necessarily your
ReallyBigObjects (since lotsOfData is really where the memory pressure
is coming from).
[Original message clipped]

null has little effect.
[Original message clipped]

Reply to this message...

Chris Lyon [MSFT] (VIP)

Hi Ivan

When the system reaches the end of a scope (like a function), the GC doesn't necessarily perform a collection. The GC collects when it runs out of free space in generation 0,
and only collects the objects with no live references, and promotes the rest to generation 1 or 2. This means it can perform a collection before or after scope ends.

In your InternalSetNull function, while you were allocating the losOfDatas, the GC needed more generation 0 space so it collected some of the lotsOfDatas, since there were no
live references to them.

In the function that didn't null anything, when a collection occured, everything got promoted a generation, since the bigObjects were live references to your lotsOfData. They
didn't get collected until after the function ended, and the bigObjects became unreachable.

So setting member variables to null/Nothing while their enclosing objects are still alive, may be better on memory.

Hope that all makes sense :)

-Chris

[Original message clipped]

--

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

Note: For the benefit of the community-at-large, all responses to this message are best directed to the newsgroup/thread from which they originated.

Reply to this message...

Dmitriy Zaslavskiy

Just to add to what Chris said.

There is a difference between debug and release mode when it comes to GC
In debug mode the references (i.e. locals) are being kept alive until
the end of function.
So in debug mode you will see the difference between setting the local
to null and not.

""Chris Lyon [MSFT]"" <Click here to reveal e-mail address> wrote in message
news:Click here to reveal e-mail address...
[Original message clipped]

Reply to this message...

Jon Skeet [C# MVP] (VIP)

Dmitriy Zaslavskiy <Click here to reveal e-mail address> wrote:
[Original message clipped]

Also note that none of this ends up being a memory *leak* as such. It
may take a bit longer for the GC to collect the memory, but it will do
so in time (assuming the relevant generation is eventually collected).

--
Jon Skeet - <Click here to reveal e-mail address>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Reply to this message...

Eric Cadwell

[Original message clipped]

I have seen Forms not collected due to the implicit root reference issue
seen in DateTimePicker and other controls. By setting references to null and
calling Dispose() on everything I can run more iterations before hitting
OutOfMemory exceptions.

As such I created this handy little function for cleaning up my resources:

public void Disposer()
{
Type type = this.GetType();
if (type != null)
{
foreach(FieldInfo fi in type.GetFields(BindingFlags.NonPublic |
BindingFlags.Instance))
{
object field = fi.GetValue(this);
if (field is IDisposable)
{
((IDisposable)field).Dispose();
Console.WriteLine("disposed field:" + fi.Name);
}
}
}
}

-Eric

Reply to this message...

Jon Skeet [C# MVP] (VIP)

Eric Cadwell <Click here to reveal e-mail address> wrote:
[Original message clipped]

Could you post a short but complete program which demonstrates the
problem?

See http://www.pobox.com/~skeet/csharp/complete.html for details of
what I mean by that.

[Original message clipped]

If you're hitting OutOfMemory exceptions at all, that suggests you've
got a leak. A leak may indeed present itself earlier if you don't set
things to null, but it shouldn't be *created* by that.

(Calling Dispose on everything is a good idea, of course.)

--
Jon Skeet - <Click here to reveal e-mail address>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Reply to this message...

Jon Skeet [C# MVP] (VIP)

Jon Skeet [C# MVP] <Click here to reveal e-mail address> wrote:
> (Calling Dispose on everything is a good idea, of course.)

Just to clarify this: I meant that making sure that everything gets
disposed appropriately is a good idea. This doesn't mean you have to
dispose of everything yourself, however.

I believe Control.Dispose disposes of everything in the Controls
collection, for instance.

--
Jon Skeet - <Click here to reveal e-mail address>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Reply to this message...

	System.Console
	System.IDisposable
	System.Reflection.BindingFlags
	System.Reflection.FieldInfo
	System.Web.UI.Control
	System.Windows.Forms.DateTimePicker

ExamGuru IT Solutions - .Net Guru is owned and operated by ExamGuru, Inc., the man behind .Net Guru. If you're in the market for bespoke software or software consultancy, why not get him and his highly trained team to help? - www.examguru.net/ITCertification

Need Dot Net Interview Questions?
Ask ExamGuru, Inc. for advice and help on Passing .Net Interviews

.Net Projects
Best-of-breed application framework for .NET projects, developed by ExamGuru, Inc. and ExamGuru IT

Free .net Help
Commission ExamGuru, Inc. and his team for your next bespoke software project

FogBUGZ
The only bug tracking system carefully crafted with one goal in mind: helping teams create great software.

Awesome Tools
If you don't know about these, you're missing out... IT Certification Questions
IT Interview Questions
Free Oracle 10g Training
MCSE Boortcamp
Cisco Study Guides
Cheap Study Guides
Exact Questions
Dot Net Interview Questions
Oracle OCP
Cheap Travel
Designer Perfumes - Wholesale Prices
Free Programming Tutorials

	Copyright © ExamGuru, Inc. 2001-2006
	Contact Us - Terms of Use - Privacy Policy - www.dot-net-guru.com - www.examguru.net - www.oraclesource.net - www.itinterviews.net - www.examguru.net/ITCertification