instansiate object

[tony]

Hello!

When I instansiate some object is then a good point to set these object to
null just to help GC to
remove this.
I mean if I might improve performance.

//Tony

 

[Nicholas Paldino [.NET/C# MVP]]

Tony,

You shouldn't. In a non debug environment, you are actually prolonging
the object's lifetime by setting it to null.

Not doing anything is the best course here.

Hope this helps.

 

[Jon Skeet [C# MVP]]

You shouldn't. In a non debug environment, you are actually prolonging
the object's lifetime by setting it to null.

In most cases it actually won't affect it either way - the object can
be collected before the assignment:

using System;

class Test
{
~Test()
{
Console.WriteLine ("Finalizer");
}

static void Main()
{
Test t = new Test();

GC.Collect();
GC.WaitForPendingFinalizers();

Console.WriteLine ("Setting t to null");
t = null;
}
}

Jon

 

[Willy Denoyette [MVP]]

| Nicholas Paldino [.NET/C# MVP] wrote:
| > You shouldn't. In a non debug environment, you are actually
prolonging
| > the object's lifetime by setting it to null.
|
| In most cases it actually won't affect it either way - the object can
| be collected before the assignment:
|
| using System;
|
| class Test
| {
| ~Test()
| {
| Console.WriteLine ("Finalizer");
| }
|
| static void Main()
| {
| Test t = new Test();
|
| GC.Collect();
| GC.WaitForPendingFinalizers();
|
| Console.WriteLine ("Setting t to null");
| t = null;
| }
| }
|
| Jon
|

Not sure what you mean here Jon, running the debug version will output:

Setting t to null
Finalizer

note that here the finalizer runs as a result of the AD shutdown,
while the release version shows:

Finalizer
Setting t to null

which actually illustrates Nicholas point, or am I missing your point.


Willy.

 

[Jon Skeet [C# MVP]]

Not sure what you mean here Jon, running the debug version will output:

Setting t to null
Finalizer

note that here the finalizer runs as a result of the AD shutdown,
while the release version shows:

Finalizer
Setting t to null

which actually illustrates Nicholas point, or am I missing your
point.

No, it doesn't illustrate Nick's point - it counters it. The only way
setting t to null could prolong the object's lifetime would be if the
GC kept the object alive due to the assignment. As the finalizer is
being run *before* the assignment, that shows the GC realises that the
variable isn't going to be *read* again, even though it will be written
- so the variable isn't treated as a GC root.

The assignment to null certainly doesn't help, but it doesn't actually
hinder the GC either.

 

[Willy Denoyette [MVP]]

| > Not sure what you mean here Jon, running the debug version will output:
| >
| > Setting t to null
| > Finalizer
| >
| > note that here the finalizer runs as a result of the AD shutdown,
| > while the release version shows:
| >
| > Finalizer
| > Setting t to null
| >
| > which actually illustrates Nicholas point, or am I missing your
| > point.
|
| No, it doesn't illustrate Nick's point - it counters it. The only way
| setting t to null could prolong the object's lifetime would be if the
| GC kept the object alive due to the assignment. As the finalizer is
| being run *before* the assignment, that shows the GC realises that the
| variable isn't going to be *read* again, even though it will be written
| - so the variable isn't treated as a GC root.
|
| The assignment to null certainly doesn't help, but it doesn't actually
| hinder the GC either.
|

Absolutely correct, I obviously mis-interpreted Nick's post.

Willy.