when to dispose a datatable?

[Miha Markic]

In contrast, on a busy server you will often see the GC run more often
because of the need to clean resources.

Memory pressure is just one of the factors that affects GC run.There are
other factors, such as server or workstation, number of CPUs, etc.

So in my experience it has been the opposite of what Cor has said, and
from everything I read you cannot predict when the GC will run, so I was
just asking Cor for some reference material to back up his statement. Do
know if what Cor said is true?

That's for Cor to provide. I think that GC runs periodically (unless an
"external" event occurs, such as low memory) regardless application is idle
or not.
IOW I don't think that GC cares about application being idle or not.

 

[William \(Bill\) Vaughn]

I concur. I've been (lectured) by the dev team that the .NET Garbage Collector (GC) runs when it feels the need to release more memory--not at scheduled or "idle" times. In theory his means on a system with lots of unused RAM, the GC might not run for hours. In my experience on systems running performance tests, it's clear that the GC chokes down performance on a regular basis, but these systems had limited RAM and lots going on. There is no truth to the rumor that the GC was designed by members a garbage handler's union that only collect trash when the streets are actually blocked.

Several points can be made:
1.. The GC behavior is different than what developers expect based on working with VB6. The GC in VB was far more aggressive and constantly kept up with released objects.
2.. The GC should not be depended on to release resources held by objects (like Connections)--we need to do that ourselves in code using Dispose (which executes Close on a Connection) or simply Close which releases the resource held by the Connection instance. The memory allocated to the object is released when the GC runs.
3.. We as developers should be more cognizant of releasing resources (like Connections and other objects) in code by closing the Connections and other resources we create.
4.. Calling Dispose does not release memory. It marks the object instance as "unused" so the GC can release the memory back to the pool.
5.. This GC behavior means that application memory allocations seem to grow over time until the GC runs.
6.. We should not try to outthink the GC. Let it do it's job. However, we do need to keep its behavior in mind as we code.
hth

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
INETA Speaker
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
Visit www.hitchhikerguides.net to get more information on my latest book:
Hitchhiker's Guide to Visual Studio and SQL Server (7th Edition)
and Hitchhiker's Guide to SQL Server 2005 Compact Edition (EBook)
-----------------------------------------------------------------------------------------------------------------------

True.

But its been my experience that the GC does most of its cleanup when there
is some level of memory pressure, not when "there is nothing else to be
done".

Matter of fact I had an application that opened a file, it set the file
object to nothing (ready for cleanup by the gc) but failed to do a close or
dispose. But because there was little activity on the machine, lots of free
memory, and the application wasn't causing sufficient memory pressure, the
gc never cleaned up the "dead" file object that still had the underlying
file open. There was definitely "nothing else to be done" on the machine and
within the application process, but the GC did not clean up the object.

In contrast, on a busy server you will often see the GC run more often
because of the need to clean resources.

So in my experience it has been the opposite of what Cor has said, and from
everything I read you cannot predict when the GC will run, so I was just
asking Cor for some reference material to back up his statement. Do know if
what Cor said is true?

 

[rowe_newsgroups]

I concur. I've been (lectured) by the dev team that the .NET Garbage Collector (GC) runs when it feels the need to release more memory--not at scheduled or "idle" times. In theory his means on a system with lots of unused RAM, the GC might not run for hours. In my experience on systems running performance tests, it's clear that the GC chokes down performance on a regular basis, but these systems had limited RAM and lots going on. There is no truth to the rumor that the GC was designed by members a garbage handler's union that only collect trash when the streets are actually blocked.

Several points can be made:
1.. The GC behavior is different than what developers expect based on working with VB6. The GC in VB was far more aggressive and constantly kept up with released objects.
2.. The GC should not be depended on to release resources held by objects (like Connections)--we need to do that ourselves in code using Dispose (which executes Close on a Connection) or simply Close which releases the resource held by the Connection instance. The memory allocated to the object is released when the GC runs.
3.. We as developers should be more cognizant of releasing resources (like Connections and other objects) in code by closing the Connections and other resources we create.
4.. Calling Dispose does not release memory. It marks the object instance as "unused" so the GC can release the memory back to the pool.
5.. This GC behavior means that application memory allocations seem to grow over time until the GC runs.
6.. We should not try to outthink the GC. Let it do it's job. However, we do need to keep its behavior in mind as we code.
hth

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
INETA Speakerwww.betav.com/blog/billvawww.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
Visitwww.hitchhikerguides.netto get more information on my latest book:
Hitchhiker's Guide to Visual Studio and SQL Server (7th Edition)
and Hitchhiker's Guide to SQL Server 2005 Compact Edition (EBook)

So Bill, what's your opinion on the Dispose / Don't Dispose topic?
Should we dispose of all IDisposable objects or just one's we know
need to be disposed (like the GDI objects)?

Sorry to drag you into a hot topic, but I'm interested to know what
you think

Thanks,

Seth Rowe

 

[Cor Ligthert [MVP]]

Seth,

That has Bill in my already answered in more sentences, for me the most
important:.

1.. We should not try to outthink the GC. Let it do it's job. However, we
do need to keep its behavior in mind as we code.
Cor

 

[Cor Ligthert [MVP]]

Nothing to add for me to this message.

Cor

"William (Bill) Vaughn" <[email protected]> schreef in bericht I concur. I've been (lectured) by the dev team that the .NET Garbage Collector (GC) runs when it feels the need to release more memory--not at scheduled or "idle" times. In theory his means on a system with lots of unused RAM, the GC might not run for hours. In my experience on systems running performance tests, it's clear that the GC chokes down performance on a regular basis, but these systems had limited RAM and lots going on. There is no truth to the rumor that the GC was designed by members a garbage handler's union that only collect trash when the streets are actually blocked.

Several points can be made:
1.. The GC behavior is different than what developers expect based on working with VB6. The GC in VB was far more aggressive and constantly kept up with released objects.
2.. The GC should not be depended on to release resources held by objects (like Connections)--we need to do that ourselves in code using Dispose (which executes Close on a Connection) or simply Close which releases the resource held by the Connection instance. The memory allocated to the object is released when the GC runs.
3.. We as developers should be more cognizant of releasing resources (like Connections and other objects) in code by closing the Connections and other resources we create.
4.. Calling Dispose does not release memory. It marks the object instance as "unused" so the GC can release the memory back to the pool.
5.. This GC behavior means that application memory allocations seem to grow over time until the GC runs.
6.. We should not try to outthink the GC. Let it do it's job. However, we do need to keep its behavior in mind as we code.
hth

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
INETA Speaker
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
Visit www.hitchhikerguides.net to get more information on my latest book:
Hitchhiker's Guide to Visual Studio and SQL Server (7th Edition)
and Hitchhiker's Guide to SQL Server 2005 Compact Edition (EBook)
-----------------------------------------------------------------------------------------------------------------------

True.

But its been my experience that the GC does most of its cleanup when there
is some level of memory pressure, not when "there is nothing else to be
done".

Matter of fact I had an application that opened a file, it set the file
object to nothing (ready for cleanup by the gc) but failed to do a close or
dispose. But because there was little activity on the machine, lots of free
memory, and the application wasn't causing sufficient memory pressure, the
gc never cleaned up the "dead" file object that still had the underlying
file open. There was definitely "nothing else to be done" on the machine and
within the application process, but the GC did not clean up the object.

In contrast, on a busy server you will often see the GC run more often
because of the need to clean resources.

So in my experience it has been the opposite of what Cor has said, and from
everything I read you cannot predict when the GC will run, so I was just
asking Cor for some reference material to back up his statement. Do know if
what Cor said is true?

 

[Brian Gideon]

So Bill, what's your opinion on the Dispose / Don't Dispose topic?
Should we dispose of all IDisposable objects or just one's we know
need to be disposed (like the GDI objects)?

Sorry to drag you into a hot topic, but I'm interested to know what
you think

Thanks,

Seth Rowe

My opinion was not solicited, but I have yet to present it in this
thread so I will do so now.

Interfaces define more than method signature contracts. They define
sematic or behavioral contracts as well. IDisposable's contract is to
release unmanaged resources held directly or indirectly by the
implementor. The presence of the interface implies that the author
already uses unmanaged resouces, intends to in a later version, or has
left the option open and wants callers to assume they are in play in
case the decision to introduce them in the future is made.

The later is important to discuss. Remember, introducing an interface
could be a version breaking change. In the case of IDisposable it
is...the documentation even says so. So an author of a class cannot
at a later time decide to use unmanaged resouces and introduce
IDisposable and still claim that the new version is backward
compatible.

Because the implication is there that unmanaged resources could be in
play at some point a caller should either always call
IDisposable.Dispose or understand the consequences of not doing so.

Personally, I never call Dispose on a DataTable because I know that it
was only brought over from MarshalByValueComponent, but I understand
that MarshalByValueComponent *could* someday do something important.
My bet is that it won't and I'm confident enough of that to choose to
ignore it.

Brian

 

[Miha Markic]

Hi Bill,

Few comments inline.

--
Miha Markic [MVP C#, INETA Country Leader for Slovenia]
RightHand .NET consulting & development www.rthand.com
Blog: http://cs.rthand.com/blogs/blog_with_righthand/
I concur. I've been (lectured) by the dev team that the .NET Garbage Collector (GC) runs when it feels the need to release more memory--not at scheduled or "idle" times.

Actually it runs often, just a memory compaction happens when necessary.

In theory his means on a system with lots of unused RAM, the GC might not run for hours. In my experience on systems running performance tests, it's clear that the GC chokes down performance on a regular basis, but these systems had limited RAM and lots going on. There is no truth to the rumor that the GC was designed by members a garbage handler's union that only collect trash when the streets are actually blocked.

Several points can be made:
1.. The GC behavior is different than what developers expect based on working with VB6. The GC in VB was far more aggressive and constantly kept up with released objects.
2.. The GC should not be depended on to release resources held by objects (like Connections)--we need to do that ourselves in code using Dispose (which executes Close on a Connection) or simply Close which releases the resource held by the Connection instance. The memory allocated to the object is released when the GC runs.
3.. We as developers should be more cognizant of releasing resources (like Connections and other objects) in code by closing the Connections and other resources we create.
4.. Calling Dispose does not release memory. It marks the object instance as "unused" so the GC can release the memory back to the pool.
It doesn't mark anything at all. It is up to the implementation what to do. Furthermore it can actually release memory - unmanaged one.
1.. This GC behavior means that application memory allocations seem to grow over time until the GC runs.
That's true but it is also true that GC does more than just release memory to external applications behind the scenes. You are actually talking about memory compaction feature, right?
1.. We should not try to outthink the GC. Let it do it's job. However, we do need to keep its behavior in mind as we code.
There are times one has/might call garbage collection. However those are very rare occasions.
hth

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
INETA Speaker
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
Visit www.hitchhikerguides.net to get more information on my latest book:
Hitchhiker's Guide to Visual Studio and SQL Server (7th Edition)
and Hitchhiker's Guide to SQL Server 2005 Compact Edition (EBook)
-----------------------------------------------------------------------------------------------------------------------

True.

But its been my experience that the GC does most of its cleanup when there
is some level of memory pressure, not when "there is nothing else to be
done".

Matter of fact I had an application that opened a file, it set the file
object to nothing (ready for cleanup by the gc) but failed to do a close or
dispose. But because there was little activity on the machine, lots of free
memory, and the application wasn't causing sufficient memory pressure, the
gc never cleaned up the "dead" file object that still had the underlying
file open. There was definitely "nothing else to be done" on the machine and
within the application process, but the GC did not clean up the object.

In contrast, on a busy server you will often see the GC run more often
because of the need to clean resources.

So in my experience it has been the opposite of what Cor has said, and from
everything I read you cannot predict when the GC will run, so I was just
asking Cor for some reference material to back up his statement. Do know if
what Cor said is true?

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

I have a list box on my form, but I need to databind it to a data table that
is a private member of the form's class... so I basically have

Public Class MyForm
priate m_MyTable as new datatable
End Class

now where would I properly dispose of this?

Never.

The DataTable class doesn't implement the IDisposable interface, it
doesn't have any Dispose method.

All the data in the DataTable object is managed. You can just let the
reference to the object go out of scope, and the garbage collector will
eventually remove the object.

 

[rowe_newsgroups]

Nothing to add for me to this message.

Cor

"William (Bill) Vaughn" <[email protected]> schreef in berichtI concur. I've been (lectured) by the dev team that the .NET Garbage Collector (GC) runs when it feels the need to release more memory--not at scheduled or "idle" times. In theory his means on a system with lots of unusedRAM, the GC might not run for hours. In my experience on systems running performance tests, it's clear that the GC chokes down performance on a regular basis, but these systems had limited RAM and lots going on. There is no truth to the rumor that the GC was designed by members a garbage handler's union that only collect trash when the streets are actually blocked.

Several points can be made:
1.. The GC behavior is different than what developers expect based onworking with VB6. The GC in VB was far more aggressive and constantly keptup with released objects.
2.. The GC should not be depended on to release resources held by objects (like Connections)--we need to do that ourselves in code using Dispose(which executes Close on a Connection) or simply Close which releases the resource held by the Connection instance. The memory allocated to the object is released when the GC runs.
3.. We as developers should be more cognizant of releasing resources (like Connections and other objects) in code by closing the Connections andother resources we create.
4.. Calling Dispose does not release memory. It marks the object instance as "unused" so the GC can release the memory back to the pool.
5.. This GC behavior means that application memory allocations seem to grow over time until the GC runs.
6.. We should not try to outthink the GC. Let it do it's job. However, we do need to keep its behavior in mind as we code.
hth

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
INETA Speaker
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
Visitwww.hitchhikerguides.netto get more information on my latest book:
Hitchhiker's Guide to Visual Studio and SQL Server (7th Edition)
and Hitchhiker's Guide to SQL Server 2005 Compact Edition (EBook)
---------------------------------------------------------------------------­--------------------------------------------




Nothing to add for me to this message.

Cor, what about Bill's first sentence:

"the .NET Garbage Collector (GC) runs when it feels the need to
release more memory--not at scheduled or "idle" times"

In both threads we have been involved in on this topic you have said
(and never backed up by the way) the statement that the GC runs at
idle times. Now you are agreeing with Bill that it does not run at
idle times.

Are you confused about something Cor?

Thanks,

Seth Rowe

 

[Brian Gideon]

Never.

The DataTable class doesn't implement the IDisposable interface, it
doesn't have any Dispose method.

All the data in the DataTable object is managed. You can just let the
reference to the object go out of scope, and the garbage collector will
eventually remove the object.

But it does subclass MarshalByValueComponent which implements
IDisposable. In the case of a DataTable the
MarshalByValueComponent.Dispose method does not do anything useful and
my guess is that it never will even in a future version. I choose to
ignore it knowing the consequences. Interestingly though, by calling
Dispose you would remove the DataTable from the finalization queue
since GC.SuppressFinalize would be called. It's been awhile, but I
believe that might prevent the object from being promoted to a higher
generation.

Brian

 

[Brian Gideon]

Personally, I never call Dispose on a DataTable because I know that it
was only brought over from MarshalByValueComponent, but I understand
that MarshalByValueComponent *could* someday do something important.
My bet is that it won't and I'm confident enough of that to choose to
ignore it.

I forgot to mention that calling Dispose on a DataTable would remove
it from the finalization queue. That would be one argument in support
of calling it.

 

[William \(Bill\) Vaughn]

I also don't call dispose--unless I know the object has implemented
IDisposable for a reason. How can one tell which to dispose and which don't
need it? That's an excellent question that does not have an easy
all-inclusive answer.

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
INETA Speaker
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
Visit www.hitchhikerguides.net to get more information on my latest book:
Hitchhiker's Guide to Visual Studio and SQL Server (7th Edition)
and Hitchhiker's Guide to SQL Server 2005 Compact Edition (EBook)
-----------------------------------------------------------------------------------------------------------------------

 

[AlexS]

You can always use this test:

if obj is IDisposable

and call Dispose accordingly

HTH
Alex

 

[Cor Ligthert [MVP]]

Seth,

I have seen that the Garbage Collector took over the proces all the time
when the graphic adapter took over the fysical proces (painting a form).
For me that is a kind of idle time, I don't know how the guys at Microsoft
implemented it, but it is for sure not as simple as you guys are telling
here in 10 lines.

However I am not every 10 minutes looking at what way the GC starts,
accoording to my first sentence I still keep it at least at idle time. And
yes it start as well as the process comes in trouble but that looks obvious
to me. However that with the graphic adapter was when the memory was all the
time under preasure. Why should you clean up memory as you have enough, I
read that so often that people want to clean up the memory. It sounds for me
like that guy, who was a coworker, he was the whole day busy cleaning up his
desktop at the office and did almost nothing more. I have known him short.

Cor



"rowe_newsgroups" <[email protected]> schreef in bericht

Nothing to add for me to this message.

Cor

"William (Bill) Vaughn" <[email protected]> schreef in
berichtI concur. I've been (lectured) by the dev team that the .NET Garbage
Collector (GC) runs when it feels the need to release more memory--not at
scheduled or "idle" times. In theory his means on a system with lots of
unused RAM, the GC might not run for hours. In my experience on systems
running performance tests, it's clear that the GC chokes down performance
on a regular basis, but these systems had limited RAM and lots going on.
There is no truth to the rumor that the GC was designed by members a
garbage handler's union that only collect trash when the streets are
actually blocked.

Several points can be made:
1.. The GC behavior is different than what developers expect based on
working with VB6. The GC in VB was far more aggressive and constantly kept
up with released objects.
2.. The GC should not be depended on to release resources held by
objects (like Connections)--we need to do that ourselves in code using
Dispose (which executes Close on a Connection) or simply Close which
releases the resource held by the Connection instance. The memory
allocated to the object is released when the GC runs.
3.. We as developers should be more cognizant of releasing resources
(like Connections and other objects) in code by closing the Connections
and other resources we create.
4.. Calling Dispose does not release memory. It marks the object
instance as "unused" so the GC can release the memory back to the pool.
5.. This GC behavior means that application memory allocations seem to
grow over time until the GC runs.
6.. We should not try to outthink the GC. Let it do it's job. However,
we do need to keep its behavior in mind as we code.
hth

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
INETA Speaker
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no
rights.
__________________________________
Visitwww.hitchhikerguides.netto get more information on my latest book:
Hitchhiker's Guide to Visual Studio and SQL Server (7th Edition)
and Hitchhiker's Guide to SQL Server 2005 Compact Edition (EBook)
---------------------------------------------------------------------------­--------------------------------------------




Nothing to add for me to this message.

Cor, what about Bill's first sentence:

"the .NET Garbage Collector (GC) runs when it feels the need to
release more memory--not at scheduled or "idle" times"

In both threads we have been involved in on this topic you have said
(and never backed up by the way) the statement that the GC runs at
idle times. Now you are agreeing with Bill that it does not run at
idle times.

Are you confused about something Cor?

Thanks,

Seth Rowe

 

[AMoose]

I see what you mean by "idle" time but you are confusing the OS scheduling
with the GC.

In your graphics card example, the GC wanted to run but had to wait till the
OS scheduled it to run.

In my file object example, the GC didn't want to run at all, even though
there was a "dead" file object to be cleaned up that had a real OS file
open.

See the difference?

Going back to dispose, calling dispose whether it does something or not,
does not effect when the OS schedules the GC nor does it effect when GC
wants to run. So when you relate calling dispose to when the GC runs or when
the OS schedules the GC to run in idle time or when a developer calls
dispose they are interferring with the GC mechanism, that relation does not
exist and you are redirecting the dispose subject to a whole other subject.

As for my philisophy for calling dispose, I have never seen any problems
being proactive and calling dispose when implemented, but I have seen
problems when developers ignore calling dispose. So when I'm asked whether
dispose should be called, in the general case I say yes. But if we get into
a discussion this is my advice:

1) if the developer asking the dispose question can say they will take
responsibility for analyzing the class's dispose method and they can be sure
it does not need to be called AND they will take responsibility for all
future implementations of the class, then go ahead and determine if the
dispose should be called and do what ever they deem good practice.

2) if the developer does not say yes to 1), then I say just call dispose and
be done with it.

But I never just answer generally "No don't call dispose".

 

[rowe_newsgroups]

Seth,

I have seen that the Garbage Collector took over the proces all the time
when the graphic adapter took over the fysical proces (painting a form).
For me that is a kind of idle time, I don't know how the guys at Microsoft
implemented it, but it is for sure not as simple as you guys are telling
here in 10 lines.

However I am not every 10 minutes looking at what way the GC starts,
accoording to my first sentence I still keep it at least at idle time. And
yes it start as well as the process comes in trouble but that looks obvious
to me. However that with the graphic adapter was when the memory was all the
time under preasure. Why should you clean up memory as you have enough, I
read that so often that people want to clean up the memory. It sounds forme
like that guy, who was a coworker, he was the whole day busy cleaning up his
desktop at the office and did almost nothing more. I have known him short.

Cor

"rowe_newsgroups" <[email protected]> schreef in bericht





Cor, what about Bill's first sentence:

"the .NET Garbage Collector (GC) runs when it feels the need to
release more memory--not at scheduled or "idle" times"

In both threads we have been involved in on this topic you have said
(and never backed up by the way) the statement that the GC runs at
idle times. Now you are agreeing with Bill that it does not run at
idle times.

Are you confused about something Cor?

Thanks,

Seth Rowe

Cor, let me start by saying I'm trying to pick a fight with you or
discredit you (though my first post in this thread may have seemed
like a trolling remark - it wasn't). There is a lot of confusion about
the GC and IDisposible and I'm trying remove some of this confusion.

I have seen that the Garbage Collector took over the proces all the time
when the graphic adapter took over the fysical proces (painting a form).
For me that is a kind of idle time, I don't know how the guys at Microsoft
implemented it, but it is for sure not as simple as you guys are telling
here in 10 lines.

However I am not every 10 minutes looking at what way the GC starts,
accoording to my first sentence I still keep it at least at idle time.

Well at least I know of you definition of "idle" time - but I would
still like to see some documentation or sample demonstrating this. I
and many others have asked you for this but you have yet never
provided any.

And
yes it start as well as the process comes in trouble but that looks obvious
to me.

I think we all agree that the GC runs when the app is under memory
pressure. The two points we have been arguing about is whether or not
the GC runs at "idle" times and whether or not to dispose of an
object when you aren't sure of whether you need to or not. Here are my
opinions:

1) The GC runs at idle times

I don't believe it does - unless it's by coincidence (like you run a
massive process that would create memory pressure and go directly to
only painting). I could easily be wrong on this (I don't know
everything), but it seems to me like the GC does not detect and run at
idle times like you suggest - especially if thats what the dev team
told Bill Vaughn.

2) Disposing when you're not sure if you should

Like in the last thread, I believe you should go ahead and call
dispose - if for no reason other than it stops the GC from having to
call the Finalize method (assuming the object uses SuppressFinalize).
This should at least help the GC do it's job better correct?

However that with the graphic adapter was when the memory was all the
time under preasure. Why should you clean up memory as you have enough, I
read that so often that people want to clean up the memory. It sounds forme
like that guy, who was a coworker, he was the whole day busy cleaning up his
desktop at the office and did almost nothing more. I have known him short.

I'm not talking about making sure every object is cleaned and released
in the most efficient manner - I'm merely talking about helping the GC
out. Using you example, I'm not saying spend all day cleaning your
desk when you have an excellent cleaning staff. I saying if you wad up
a piece of scrap paper, don't throw it on the floor and let the
cleaning staff put it in the trashcan before they empty your trash,
instead throw the paper into the trashcan and save the cleaning staff
the extra step.

Thanks,

Seth Rowe

 

[Cor Ligthert [MVP]]

Seth,

Because the dispose story comes at least every half year in the VB newsgroup
and 2 times a month in the AdoNet newsgroup I am not fighting anymore, I
have investigate it more or less for X (I can get here name, she lives in
America and is original Russian she is now MVP) when had a problem told that
in the general newsgroup. Nowbody was real helping her.

In fact it does not bother me at all as long as I have enough memory. (I had
never any problem at home with .5GB exept with the Beta from 2005.

I even am not interested how much memory I have in my computer at my job as
long as it is enough.

What bothers me that people thinks that doing an extra proces as dispose
takes no time. Every process takes at least one cycle.

You can reat this, it is written by Jay B. Harlow in the discusssion from
next year. I agree almost complete with this. (He changed his vision on some
points in this article).

http://groups.google.com/group/microsoft.public.dotnet.languages.vb/msg/dcc9c7faa7f3bf19?hl=en&

Cor





"rowe_newsgroups" <[email protected]> schreef in bericht

Seth,

I have seen that the Garbage Collector took over the proces all the time
when the graphic adapter took over the fysical proces (painting a form).
For me that is a kind of idle time, I don't know how the guys at Microsoft
implemented it, but it is for sure not as simple as you guys are telling
here in 10 lines.

However I am not every 10 minutes looking at what way the GC starts,
accoording to my first sentence I still keep it at least at idle time. And
yes it start as well as the process comes in trouble but that looks
obvious
to me. However that with the graphic adapter was when the memory was all
the
time under preasure. Why should you clean up memory as you have enough, I
read that so often that people want to clean up the memory. It sounds for
me
like that guy, who was a coworker, he was the whole day busy cleaning up
his
desktop at the office and did almost nothing more. I have known him short.

Cor

"rowe_newsgroups" <[email protected]> schreef in
bericht




Cor, what about Bill's first sentence:

"the .NET Garbage Collector (GC) runs when it feels the need to
release more memory--not at scheduled or "idle" times"

In both threads we have been involved in on this topic you have said
(and never backed up by the way) the statement that the GC runs at
idle times. Now you are agreeing with Bill that it does not run at
idle times.

Are you confused about something Cor?

Thanks,

Seth Rowe

Cor, let me start by saying I'm trying to pick a fight with you or
discredit you (though my first post in this thread may have seemed
like a trolling remark - it wasn't). There is a lot of confusion about
the GC and IDisposible and I'm trying remove some of this confusion.

I have seen that the Garbage Collector took over the proces all the time
when the graphic adapter took over the fysical proces (painting a form).
For me that is a kind of idle time, I don't know how the guys at Microsoft
implemented it, but it is for sure not as simple as you guys are telling
here in 10 lines.

However I am not every 10 minutes looking at what way the GC starts,
accoording to my first sentence I still keep it at least at idle time.

Well at least I know of you definition of "idle" time - but I would
still like to see some documentation or sample demonstrating this. I
and many others have asked you for this but you have yet never
provided any.

And
yes it start as well as the process comes in trouble but that looks
obvious
to me.

I think we all agree that the GC runs when the app is under memory
pressure. The two points we have been arguing about is whether or not
the GC runs at "idle" times and whether or not to dispose of an
object when you aren't sure of whether you need to or not. Here are my
opinions:

1) The GC runs at idle times

I don't believe it does - unless it's by coincidence (like you run a
massive process that would create memory pressure and go directly to
only painting). I could easily be wrong on this (I don't know
everything), but it seems to me like the GC does not detect and run at
idle times like you suggest - especially if thats what the dev team
told Bill Vaughn.

2) Disposing when you're not sure if you should

Like in the last thread, I believe you should go ahead and call
dispose - if for no reason other than it stops the GC from having to
call the Finalize method (assuming the object uses SuppressFinalize).
This should at least help the GC do it's job better correct?

However that with the graphic adapter was when the memory was all the
time under preasure. Why should you clean up memory as you have enough, I
read that so often that people want to clean up the memory. It sounds for
me
like that guy, who was a coworker, he was the whole day busy cleaning up
his
desktop at the office and did almost nothing more. I have known him short.

I'm not talking about making sure every object is cleaned and released
in the most efficient manner - I'm merely talking about helping the GC
out. Using you example, I'm not saying spend all day cleaning your
desk when you have an excellent cleaning staff. I saying if you wad up
a piece of scrap paper, don't throw it on the floor and let the
cleaning staff put it in the trashcan before they empty your trash,
instead throw the paper into the trashcan and save the cleaning staff
the extra step.

Thanks,

Seth Rowe

 

[Cor Ligthert [MVP]]

When I had sent the message and I scrolled down I saw a name like Marina,
which it was.

"rowe_newsgroups" <[email protected]> schreef in bericht

Seth,

I have seen that the Garbage Collector took over the proces all the time
when the graphic adapter took over the fysical proces (painting a form).
For me that is a kind of idle time, I don't know how the guys at Microsoft
implemented it, but it is for sure not as simple as you guys are telling
here in 10 lines.

However I am not every 10 minutes looking at what way the GC starts,
accoording to my first sentence I still keep it at least at idle time. And
yes it start as well as the process comes in trouble but that looks
obvious
to me. However that with the graphic adapter was when the memory was all
the
time under preasure. Why should you clean up memory as you have enough, I
read that so often that people want to clean up the memory. It sounds for
me
like that guy, who was a coworker, he was the whole day busy cleaning up
his
desktop at the office and did almost nothing more. I have known him short.

Cor

"rowe_newsgroups" <[email protected]> schreef in
bericht




Cor, what about Bill's first sentence:

"the .NET Garbage Collector (GC) runs when it feels the need to
release more memory--not at scheduled or "idle" times"

In both threads we have been involved in on this topic you have said
(and never backed up by the way) the statement that the GC runs at
idle times. Now you are agreeing with Bill that it does not run at
idle times.

Are you confused about something Cor?

Thanks,

Seth Rowe

Cor, let me start by saying I'm trying to pick a fight with you or
discredit you (though my first post in this thread may have seemed
like a trolling remark - it wasn't). There is a lot of confusion about
the GC and IDisposible and I'm trying remove some of this confusion.

I have seen that the Garbage Collector took over the proces all the time
when the graphic adapter took over the fysical proces (painting a form).
For me that is a kind of idle time, I don't know how the guys at Microsoft
implemented it, but it is for sure not as simple as you guys are telling
here in 10 lines.

However I am not every 10 minutes looking at what way the GC starts,
accoording to my first sentence I still keep it at least at idle time.

Well at least I know of you definition of "idle" time - but I would
still like to see some documentation or sample demonstrating this. I
and many others have asked you for this but you have yet never
provided any.

And
yes it start as well as the process comes in trouble but that looks
obvious
to me.

I think we all agree that the GC runs when the app is under memory
pressure. The two points we have been arguing about is whether or not
the GC runs at "idle" times and whether or not to dispose of an
object when you aren't sure of whether you need to or not. Here are my
opinions:

1) The GC runs at idle times

I don't believe it does - unless it's by coincidence (like you run a
massive process that would create memory pressure and go directly to
only painting). I could easily be wrong on this (I don't know
everything), but it seems to me like the GC does not detect and run at
idle times like you suggest - especially if thats what the dev team
told Bill Vaughn.

2) Disposing when you're not sure if you should

Like in the last thread, I believe you should go ahead and call
dispose - if for no reason other than it stops the GC from having to
call the Finalize method (assuming the object uses SuppressFinalize).
This should at least help the GC do it's job better correct?

However that with the graphic adapter was when the memory was all the
time under preasure. Why should you clean up memory as you have enough, I
read that so often that people want to clean up the memory. It sounds for
me
like that guy, who was a coworker, he was the whole day busy cleaning up
his
desktop at the office and did almost nothing more. I have known him short.

I'm not talking about making sure every object is cleaned and released
in the most efficient manner - I'm merely talking about helping the GC
out. Using you example, I'm not saying spend all day cleaning your
desk when you have an excellent cleaning staff. I saying if you wad up
a piece of scrap paper, don't throw it on the floor and let the
cleaning staff put it in the trashcan before they empty your trash,
instead throw the paper into the trashcan and save the cleaning staff
the extra step.

Thanks,

Seth Rowe

 

[rowe_newsgroups]

Seth,

Because the dispose story comes at least every half year in the VB newsgroup
and 2 times a month in the AdoNet newsgroup I am not fighting anymore, I
have investigate it more or less for X (I can get here name, she lives in
America and is original Russian she is now MVP) when had a problem told that
in the general newsgroup. Nowbody was real helping her.

In fact it does not bother me at all as long as I have enough memory. (I had
never any problem at home with .5GB exept with the Beta from 2005.

I even am not interested how much memory I have in my computer at my job as
long as it is enough.

What bothers me that people thinks that doing an extra proces as dispose
takes no time. Every process takes at least one cycle.

You can reat this, it is written by Jay B. Harlow in the discusssion from
next year. I agree almost complete with this. (He changed his vision on some
points in this article).

http://groups.google.com/group/microsoft.public.dotnet.languages.vb/m...

Cor

"rowe_newsgroups" <[email protected]> schreef in bericht

Seth,

I have seen that the Garbage Collector took over the proces all the time
when the graphic adapter took over the fysical proces (painting a form).
For me that is a kind of idle time, I don't know how the guys at Microsoft
implemented it, but it is for sure not as simple as you guys are telling
here in 10 lines.

However I am not every 10 minutes looking at what way the GC starts,
accoording to my first sentence I still keep it at least at idle time. And
yes it start as well as the process comes in trouble but that looks
obvious
to me. However that with the graphic adapter was when the memory was all
the
time under preasure. Why should you clean up memory as you have enough,I
read that so often that people want to clean up the memory. It sounds for
me
like that guy, who was a coworker, he was the whole day busy cleaning up
his
desktop at the office and did almost nothing more. I have known him short.

Cor

"rowe_newsgroups" <[email protected]> schreef in
berichtOn Jun 13, 2:36 pm, "Cor Ligthert [MVP]" <[email protected]>
wrote:

Nothing to add for me to this message.
Cor
"William (Bill) Vaughn" <[email protected]> schreef in
berichtI concur. I've been (lectured) by the dev team that the .NET Garbage
Collector (GC) runs when it feels the need to release more memory--not
at
scheduled or "idle" times. In theory his means on a system with lots of
unused RAM, the GC might not run for hours. In my experience on systems
running performance tests, it's clear that the GC chokes down
performance
on a regular basis, but these systems had limited RAM and lots going on.
There is no truth to the rumor that the GC was designed by members a
garbage handler's union that only collect trash when the streets are
actually blocked.
Several points can be made:
1.. The GC behavior is different than what developers expect based
on
working with VB6. The GC in VB was far more aggressive and constantly
kept
up with released objects.
2.. The GC should not be depended on to release resources held by
objects (like Connections)--we need to do that ourselves in code using
Dispose (which executes Close on a Connection) or simply Close which
releases the resource held by the Connection instance. The memory
allocated to the object is released when the GC runs.
3.. We as developers should be more cognizant of releasing resources
(like Connections and other objects) in code by closing the Connections
and other resources we create.
4.. Calling Dispose does not release memory. It marks the object
instance as "unused" so the GC can release the memory back to the pool.
5.. This GC behavior means that application memory allocations seem
to
grow over time until the GC runs.
6.. We should not try to outthink the GC. Let it do it's job.
However,
we do need to keep its behavior in mind as we code.
hth
--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
INETA Speaker
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no
rights.
__________________________________
Visitwww.hitchhikerguides.nettogetmore information on my latest book:
Hitchhiker's Guide to Visual Studio and SQL Server (7th Edition)
and Hitchhiker's Guide to SQL Server 2005 Compact Edition (EBook)
---------------------------------------------------------------------------­--------------------------------------------
messageTrue.
But its been my experience that the GC does most of its cleanup when
there
is some level of memory pressure, not when "there is nothing elseto
be
done".
Matter of fact I had an application that opened a file, it set the
file
object to nothing (ready for cleanup by the gc) but failed to do a
close or
dispose. But because there was little activity on the machine, lots
of
free
memory, and the application wasn't causing sufficient memory
pressure,
the
gc never cleaned up the "dead" file object that still had the
underlying
file open. There was definitely "nothing else to be done" on the
machine and
within the application process, but the GC did not clean up the
object.
In contrast, on a busy server you will often see the GC run more
often
because of the need to clean resources.
So in my experience it has been the opposite of what Cor has said,
and
from
everything I read you cannot predict when the GC will run, so I was
just
asking Cor for some reference material to back up his statement. Do
know if
what Cor said is true?
"Miha Markic" <miha at rthand com> wrote in message

Cor,
Can you provide a link to documentation where it states that the
GC
does
cleanup when there is nothing else to be done?
GC does cleanup when it decides to do it. It has a built in smart
scheduler that should do in most cases.
--
Miha Markic [MVP C#, INETA Country Leader for Slovenia]
RightHand .NET consulting & developmentwww.rthand.com
Blog:http://cs.rthand.com/blogs/blog_with_righthand/
Nothing to add for me to this message.

Cor, what about Bill's first sentence:

"the .NET Garbage Collector (GC) runs when it feels the need to
release more memory--not at scheduled or "idle" times"

In both threads we have been involved in on this topic you have said
(and never backed up by the way) the statement that the GC runs at
idle times. Now you are agreeing with Bill that it does not run at
idle times.

Are you confused about something Cor?

Seth Rowe

Cor, let me start by saying I'm trying to pick a fight with you or
discredit you (though my first post in this thread may have seemed
like a trolling remark - it wasn't). There is a lot of confusion about
the GC and IDisposible and I'm trying remove some of this confusion.

I have seen that the Garbage Collector took over the proces all the time
when the graphic adapter took over the fysical proces (painting a form).
For me that is a kind of idle time, I don't know how the guys at Microsoft
implemented it, but it is for sure not as simple as you guys are telling
here in 10 lines.

However I am not every 10 minutes looking at what way the GC starts,
accoording to my first sentence I still keep it at least at idle time.

Well at least I know of you definition of "idle" time - but I would
still like to see some documentation or sample demonstrating this. I
and many others have asked you for this but you have yet never
provided any.

And
yes it start as well as the process comes in trouble but that looks
obvious
to me.

I think we all agree that the GC runs when the app is under memory
pressure. The two points we have been arguing about is whether or not
the GC runs at "idle" times and whether or not to dispose of an
object when you aren't sure of whether you need to or not. Here are my
opinions:

1) The GC runs at idle times

I don't believe it does - unless it's by coincidence (like you run a
massive process that would create memory pressure and go directly to
only painting). I could easily be wrong on this (I don't know
everything), but it seems to me like the GC does not detect and run at
idle times like you suggest - especially if thats what the dev team
told Bill Vaughn.

2) Disposing when you're not sure if you should

Like in the last thread, I believe you should go ahead and call
dispose - if for no reason other than it stops the GC from having to
call the Finalize method (assuming the object uses SuppressFinalize).
This should at least help the GC do it's job better correct?

However that with the graphic adapter was when the memory was all the
time under preasure. Why should you clean up memory as you have enough,I
read that so often that

...

read more »

What bothers me that people thinks that doing an extra proces as dispose
takes no time. Every process takes at least one cycle.

Yes calling Dispose takes some process time, but won't we get hit with
that anyways since eventually the GC is going to call Finalize which
in turn will call Dispose? If so calling Dispose manually will stop
the GC from needing to call Finalize which will save time, and it will
also prevent the object from reaching a higher generation. If that is
correct it seems that calling Dispose will actually save time, not
waste time.

You can reat this, it is written by Jay B. Harlow in the discusssion from
next year. I agree almost complete with this. (He changed his vision on some
points in this article).

http://groups.google.com/group/microsoft.public.dotnet.languages.vb/m...

I like the rules Jay states - they are pretty much the same as the
one's I use. (oh, I think you mean discussion from last year )

Thanks,

Seth Rowe

 

[AMoose]

In one sentence you say you are not so concerned about memory, you have
enough, but in the next sentence you go to the opposite extreme and point
out you are bothered with dispose using a few cpu cycles. See the
contradiction? Do you happen to know the cpu performance hit when calling
dispose? If so could you publish your findings to help reenforce your
concern? I'm pretty sure with the dual core cpus coming out these days,
calling empty dispose does very little to the performance of the
application.

I've never seen calling dispose cause any perfrom problems at all, like I
said I'm proactive about calling dispose and have experienced no problems at
all. While I have seen not calling dispose have a negative effect on my
server's memory and resources. So again my concerns seem to be the opposite
of yours. Plus I'm with Seth in that calling dispose may actually boost
overall performance.