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? In the finalize method? I am
loading the data for the table in a subroutine that is executed at form
load, of course all the commands tied to it are wrapped in using blocks, but
I cant wrap the table in that because it i put it in a using block then
databind it, of course it will disappear when it exits that block and then
the databinding is gone, so I made it at the class level instead and want
its life time to be that of the form.. thanks!
44  8136 
Dispose it when you don't need table anymore.
You can do that in FormClosing or in form Dispose if you implement it
HTH
"Smokey Grindle" <no****@nospam.comwrote in message
news:uM**************@TK2MSFTNGP05.phx.gbl...
>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? In the finalize method? I am
loading the data for the table in a subroutine that is executed at form
load, of course all the commands tied to it are wrapped in using blocks,
but I cant wrap the table in that because it i put it in a using block
then databind it, of course it will disappear when it exits that block and
then the databinding is gone, so I made it at the class level instead and
want its life time to be that of the form.. thanks!
Just a note that you don't actually need to dispose datatable, but it is a
good practice.
And yes, dispose it when you are done with it (form's dispose might be a
good place if you can't dispose it earlier)
--
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/
"Smokey Grindle" <no****@nospam.comwrote in message
news:uM**************@TK2MSFTNGP05.phx.gbl...
>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? In the finalize method? I am
loading the data for the table in a subroutine that is executed at form
load, of course all the commands tied to it are wrapped in using blocks,
but I cant wrap the table in that because it i put it in a using block
then databind it, of course it will disappear when it exits that block and
then the databinding is gone, so I made it at the class level instead and
want its life time to be that of the form.. thanks!
what about in a custom control? should it be in the dispose method or
finalize method? I remember this is a difference between them, i believe
that dispose is immediate and finalize can happen at any time after the
object has fallen out of scope?
"Miha Markic" <miha at rthand comwrote in message
news:07**********************************@microsof t.com...
Just a note that you don't actually need to dispose datatable, but it is a
good practice.
And yes, dispose it when you are done with it (form's dispose might be a
good place if you can't dispose it earlier)
--
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/
"Smokey Grindle" <no****@nospam.comwrote in message
news:uM**************@TK2MSFTNGP05.phx.gbl...
>>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? In the finalize method? I am
loading the data for the table in a subroutine that is executed at form
load, of course all the commands tied to it are wrapped in using blocks,
but I cant wrap the table in that because it i put it in a using block
then databind it, of course it will disappear when it exits that block
and then the databinding is gone, so I made it at the class level instead
and want its life time to be that of the form.. thanks!
Finalize is a place for disposing *unmanaged* controls.
Furthermore, controls placed on form are disposed automatically when form is
disposed, so no action is required.
--
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/
"Smokey Grindle" <no****@nospam.comwrote in message
news:eV**************@TK2MSFTNGP03.phx.gbl...
what about in a custom control? should it be in the dispose method or
finalize method? I remember this is a difference between them, i believe
that dispose is immediate and finalize can happen at any time after the
object has fallen out of scope?
"Miha Markic" <miha at rthand comwrote in message
news:07**********************************@microsof t.com...
>Just a note that you don't actually need to dispose datatable, but it is
a good practice.
And yes, dispose it when you are done with it (form's dispose might be a
good place if you can't dispose it earlier)
--
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/
"Smokey Grindle" <no****@nospam.comwrote in message
news:uM**************@TK2MSFTNGP05.phx.gbl...
>>>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? In the finalize method? I am
loading the data for the table in a subroutine that is executed at form
load, of course all the commands tied to it are wrapped in using blocks,
but I cant wrap the table in that because it i put it in a using block
then databind it, of course it will disappear when it exits that block
and then the databinding is gone, so I made it at the class level
instead and want its life time to be that of the form.. thanks!
Miha,
Not only on forms, this is as well for components or whereever there where
Idisposible is nice implemented.
I assume you knew this, so for the OP.
Cor
"Miha Markic" <miha at rthand comschreef in bericht
news:1C**********************************@microsof t.com...
Finalize is a place for disposing *unmanaged* controls.
Furthermore, controls placed on form are disposed automatically when form
is disposed, so no action is required.
--
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/
"Smokey Grindle" <no****@nospam.comwrote in message
news:eV**************@TK2MSFTNGP03.phx.gbl...
>what about in a custom control? should it be in the dispose method or
finalize method? I remember this is a difference between them, i believe
that dispose is immediate and finalize can happen at any time after the
object has fallen out of scope?
"Miha Markic" <miha at rthand comwrote in message
news:07**********************************@microso ft.com...
>>Just a note that you don't actually need to dispose datatable, but it is
a good practice.
And yes, dispose it when you are done with it (form's dispose might be a
good place if you can't dispose it earlier)
--
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/
"Smokey Grindle" <no****@nospam.comwrote in message
news:uM**************@TK2MSFTNGP05.phx.gbl...
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? In the finalize method? I
am loading the data for the table in a subroutine that is executed at
form load, of course all the commands tied to it are wrapped in using
blocks, but I cant wrap the table in that because it i put it in a
using block then databind it, of course it will disappear when it exits
that block and then the databinding is gone, so I made it at the class
level instead and want its life time to be that of the form.. thanks!
Smokey,
In the Data namespace there is only one thing that can be disposed, which is
up to you and that is the connection. As you use the using clause it is even
astatically disposed.
Dispose is not (read not) the same as finalizing, you are using managed
code, it is setting the object ready for removing by the GC. Some people
think that how quicker they do that how better. If there is no need for
extra resources, it is the opposite. So let your managed code do the work,
and interfere not in that what the developers by Microsoft made for you.
Cor
"Smokey Grindle" <no****@nospam.comschreef in bericht
news:uM**************@TK2MSFTNGP05.phx.gbl...
>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? In the finalize method? I am
loading the data for the table in a subroutine that is executed at form
load, of course all the commands tied to it are wrapped in using blocks,
but I cant wrap the table in that because it i put it in a using block
then databind it, of course it will disappear when it exits that block and
then the databinding is gone, so I made it at the class level instead and
want its life time to be that of the form.. thanks!
"Cor Ligthert [MVP]" <no************@planet.nlwrote in message
news:%2****************@TK2MSFTNGP03.phx.gbl...
Smokey,
In the Data namespace there is only one thing that can be disposed, which
is up to you and that is the connection. As you use the using clause it is
even astatically disposed.
Dispose is not (read not) the same as finalizing, you are using managed
code, it is setting the object ready for removing by the GC.
No, Dispose doesn't affect the GC for the instance where Dispose is called
in any way whatsoever.
IOW if you call someobject.Dispose() it won't affect the GC for someobject.
Some people
think that how quicker they do that how better. If there is no need for
extra resources, it is the opposite. So let your managed code do the work,
and interfere not in that what the developers by Microsoft made for you.
I assume you are talking about Data namespace where Dispose usually does not
very much.
However, in general, Dispose has to be called to release resources.
Furthermore even on classes that doesn't handle unmanaged code directly the
Dispose might be of help. It might set references to other objects to null
thus leaving those objects for garbage collection.
Basically I recommended to call Dispose always when IDisposable is involved.
Even if you know that Dispose does nothing the situation might change in the
future.
--
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/
Miha,
Even if you know that Dispose does nothing the situation might change in
the future.
Yea the same with the + sign, maybe it subtracts in future,
Both the VB and the C# team take a lot of time to see that there are no
breaking change, they surely won't do that in the case of the Dispose.
Cor
--
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/
Both the VB and the C# team take a lot of time to see that there are no
breaking change, they surely won't do that in the case of the Dispose.
What exactly have language teams with BCL implementation (IOW Dispose
implementation)? And what do they have with 3rd party software Dispose
implementation?
You are certainly not saying that language teams control Dispose
implementation of all classes on the world, do you?
--
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/
On Mon, 11 Jun 2007 19:04:42 +0200, "Cor Ligthert [MVP]"
<no************@planet.nlwrote:
>Smokey,
In the Data namespace there is only one thing that can be disposed, which is
up to you and that is the connection. As you use the using clause it is even
astatically disposed.
How do you know this? Is it documented anywhere?
I have been disposing all of the Data namespace items because I didn't
know if I needed to to not.
On Jun 12, 1:38 pm, "Miha Markic" <miha at rthand comwrote:
Both the VB and the C# team take a lot of time to see that there are no
breaking change, they surely won't do that in the case of the Dispose.
What exactly have language teams with BCL implementation (IOW Dispose
implementation)? And what do they have with 3rd party software Dispose
implementation?
You are certainly not saying that language teams control Dispose
implementation of all classes on the world, do you?
--
Miha Markic [MVP C#, INETA Country Leader for Slovenia]
RightHand .NET consulting & developmentwww.rthand.com
Blog:http://cs.rthand.com/blogs/blog_with_righthand/
Miha - just as a warning - I along with many others have been down
this path with Cor quite a few times to no avail. You're welcome to
keep trying but I doubt anything will change.
Thanks,
Seth Rowe
Miha - just as a warning - I along with many others have been down
this path with Cor quite a few times to no avail. You're welcome to
keep trying but I doubt anything will change.
:-) Yes, yes, I know. I am actually not trying to go that path. I just can't
let false statements about disposing flow here.
There is already so much Dispose/GC misunderstandings all over the
community...
--
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/
On Jun 11, 12:04 pm, "Cor Ligthert [MVP]" <notmyfirstn...@planet.nl>
wrote:
Dispose is not (read not) the same as finalizing, you are using managed
code, it is setting the object ready for removing by the GC. Some people
think that how quicker they do that how better. If there is no need for
extra resources, it is the opposite. So let your managed code do the work,
and interfere not in that what the developers by Microsoft made for you.
In most cases it is imperative to call Dispose as soon as the object
is no longer needed. An argument could be made that a DataTable is an
excpetion to that rule, but a FileHandle, IDbConnection, and the like
are not.
The canonical implementation of Dispose will only prevent the GC from
calling Finalize via GC.SuppressFinalize. Other than that the garbage
collection process is same as with any other class.
Also, are you saying that it is better to avoid calling Dispose?
Brian
Brian,
I am not saying it is better, I see this however often in relation with
cleaning memory.
Cleaning memory takes time and gives nothing back. So let it be done in the
proper time, when there is nothing else to be done, something the GC is
standard doing.
Cor
"Brian Gideon" <br*********@yahoo.comschreef in bericht
news:11**********************@g37g2000prf.googlegr oups.com...
On Jun 11, 12:04 pm, "Cor Ligthert [MVP]" <notmyfirstn...@planet.nl>
wrote:
>Dispose is not (read not) the same as finalizing, you are using managed
code, it is setting the object ready for removing by the GC. Some people
think that how quicker they do that how better. If there is no need for
extra resources, it is the opposite. So let your managed code do the
work,
and interfere not in that what the developers by Microsoft made for you.
In most cases it is imperative to call Dispose as soon as the object
is no longer needed. An argument could be made that a DataTable is an
excpetion to that rule, but a FileHandle, IDbConnection, and the like
are not.
The canonical implementation of Dispose will only prevent the GC from
calling Finalize via GC.SuppressFinalize. Other than that the garbage
collection process is same as with any other class.
Also, are you saying that it is better to avoid calling Dispose?
Brian
Cor,
Can you provide a link to documentation where it states that the GC does
cleanup when there is nothing else to be done?
Thanks
Moose
"Cor Ligthert [MVP]" <no************@planet.nlwrote in message
news:%2****************@TK2MSFTNGP06.phx.gbl...
Brian,
I am not saying it is better, I see this however often in relation with
cleaning memory.
Cleaning memory takes time and gives nothing back. So let it be done in
the proper time, when there is nothing else to be done, something the GC
is standard doing.
Cor
"Brian Gideon" <br*********@yahoo.comschreef in bericht
news:11**********************@g37g2000prf.googlegr oups.com...
>On Jun 11, 12:04 pm, "Cor Ligthert [MVP]" <notmyfirstn...@planet.nl>
wrote:
>>Dispose is not (read not) the same as finalizing, you are using managed
code, it is setting the object ready for removing by the GC. Some people
think that how quicker they do that how better. If there is no need for
extra resources, it is the opposite. So let your managed code do the
work,
and interfere not in that what the developers by Microsoft made for you.
In most cases it is imperative to call Dispose as soon as the object
is no longer needed. An argument could be made that a DataTable is an
excpetion to that rule, but a FileHandle, IDbConnection, and the like
are not.
The canonical implementation of Dispose will only prevent the GC from
calling Finalize via GC.SuppressFinalize. Other than that the garbage
collection process is same as with any other class.
Also, are you saying that it is better to avoid calling Dispose?
Brian
Hi Brian,
The canonical implementation of Dispose will only prevent the GC from
calling Finalize via GC.SuppressFinalize. Other than that the garbage
collection process is same as with any other class.
Not exactly true. SuppressFinalize is only required if a finalizer is
implemented. And you need a finalizer only when you are dealing with
unmanaged memory which is very rare. Thus the canonical implementation is to
dispose child objects and nothing more.
--
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/
"Cor Ligthert [MVP]" <no************@planet.nlwrote in message
news:%2****************@TK2MSFTNGP06.phx.gbl...
Brian,
I am not saying it is better, I see this however often in relation with
cleaning memory.
Cleaning memory takes time and gives nothing back.
Well, it gives back free memory :-)
So let it be done in the
proper time, when there is nothing else to be done, something the GC is
standard doing.
The only relation between Dispose and cleaning memory/GC is in the fact that
Dispose implementation *might* release references to objects. Dispose
doesn't affect the scheduling of GC.
--
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/
"AMoose" <No@Where.comwrote in message
news:m9******************************@giganews.com ...
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 & development www.rthand.com
Blog: http://cs.rthand.com/blogs/blog_with_righthand/
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?
"Miha Markic" <miha at rthand comwrote in message
news:53**********************************@microsof t.com...
>
"AMoose" <No@Where.comwrote in message
news:m9******************************@giganews.com ...
>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 & development www.rthand.com
Blog: http://cs.rthand.com/blogs/blog_with_righthand/
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.
--
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. 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)
-----------------------------------------------------------------------------------------------------------------------
"AMoose" <No@Where.comwrote in message news:Cf******************************@giganews.com ...
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?
"Miha Markic" <miha at rthand comwrote in message
news:53**********************************@microsof t.com...
>>
"AMoose" <No@Where.comwrote in message
news:m9******************************@giganews.co m...
>>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 & development www.rthand.com
Blog: http://cs.rthand.com/blogs/blog_with_righthand/
On Jun 13, 1:16 pm, "William \(Bill\) Vaughn"
<billvaRemoveT...@betav.comwrote:
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)
-----------------------------------------------------------------------------------------------------------------------
"AMoose" <N...@Where.comwrote in messagenews:Cf******************************@gigan ews.com...
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?
"Miha Markic" <miha at rthand comwrote in message
news:53**********************************@microsof t.com...
"AMoose" <N...@Where.comwrote in message
news:m9******************************@giganews.co m...
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/
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
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
"rowe_newsgroups" <ro********@yahoo.comschreef in bericht
news:11**********************@z28g2000prd.googlegr oups.com...
On Jun 13, 1:16 pm, "William \(Bill\) Vaughn"
<billvaRemoveT...@betav.comwrote:
>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)
-----------------------------------------------------------------------------------------------------------------------
"AMoose" <N...@Where.comwrote in
messagenews:Cf******************************@giga news.com...
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?
"Miha Markic" <miha at rthand comwrote in message
news:53**********************************@microso ft.com...
>"AMoose" <N...@Where.comwrote in message
news:m9******************************@giganews.c om...
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/
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
Nothing to add for me to this message.
Cor
"William (Bill) Vaughn" <bi**************@betav.comschreef in bericht news:uZ**************@TK2MSFTNGP02.phx.gbl...
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)
-----------------------------------------------------------------------------------------------------------------------
"AMoose" <No@Where.comwrote in message news:Cf******************************@giganews.com ...
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?
"Miha Markic" <miha at rthand comwrote in message
news:53**********************************@microsof t.com...
>>
"AMoose" <No@Where.comwrote in message
news:m9******************************@giganews.co m...
>>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 & development www.rthand.com
Blog: http://cs.rthand.com/blogs/blog_with_righthand/
On Jun 13, 12:29 pm, rowe_newsgroups <rowe_em...@yahoo.comwrote:
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
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/
"William (Bill) Vaughn" <bi**************@betav.comwrote in message news:uZ**************@TK2MSFTNGP02.phx.gbl...
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)
-----------------------------------------------------------------------------------------------------------------------
"AMoose" <No@Where.comwrote in message news:Cf******************************@giganews.com ...
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?
"Miha Markic" <miha at rthand comwrote in message
news:53**********************************@microsof t.com...
>>
"AMoose" <No@Where.comwrote in message
news:m9******************************@giganews.co m...
>>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 & development www.rthand.com
Blog: http://cs.rthand.com/blogs/blog_with_righthand/
Smokey Grindle wrote:
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.
--
Göran Andersson
_____ http://www.guffa.com
On Jun 13, 2:36 pm, "Cor Ligthert [MVP]" <notmyfirstn...@planet.nl>
wrote:
Nothing to add for me to this message.
Cor
"William (Bill) Vaughn" <billvaRemoveT...@betav.comschreef in berichtnews:uZ**************@TK2MSFTNGP02.phx.gbl. ..
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 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)
---------------------------------------------------------------------------*--------------------------------------------
"AMoose" <N...@Where.comwrote in messagenews:Cf******************************@gigan ews.com...
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?
>
>
"Miha Markic" <miha at rthand comwrote in message
>news:53**********************************@microso ft.com...
>>
>"AMoose" <N...@Where.comwrote in message
>>news:m9******************************@giganews.c om...
>>Cor,
>>>
>>Can you provide a link to documentation where it states that the GCdoes
>>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?
Thanks,
Seth Rowe
On Jun 13, 3:01 pm, Göran Andersson <g...@guffa.comwrote:
Smokey Grindle wrote:
I have a list box on my form, but I need to databind it to a data tablethat
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.
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
On Jun 13, 1:43 pm, Brian Gideon <briangid...@yahoo.comwrote:
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.
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)
-----------------------------------------------------------------------------------------------------------------------
"Brian Gideon" <br*********@yahoo.comwrote in message
news:11*********************@j4g2000prf.googlegrou ps.com...
On Jun 13, 12:29 pm, rowe_newsgroups <rowe_em...@yahoo.comwrote:
>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
You can always use this test:
if obj is IDisposable
and call Dispose accordingly
HTH
Alex
"William (Bill) Vaughn" <bi**************@betav.comwrote in message
news:%2******************@TK2MSFTNGP03.phx.gbl...
>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)
-----------------------------------------------------------------------------------------------------------------------
"Brian Gideon" <br*********@yahoo.comwrote in message
news:11*********************@j4g2000prf.googlegrou ps.com...
>On Jun 13, 12:29 pm, rowe_newsgroups <rowe_em...@yahoo.comwrote:
>>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
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" <ro********@yahoo.comschreef in bericht
news:11**********************@i13g2000prf.googlegr oups.com...
On Jun 13, 2:36 pm, "Cor Ligthert [MVP]" <notmyfirstn...@planet.nl>
wrote:
Nothing to add for me to this message.
Cor
"William (Bill) Vaughn" <billvaRemoveT...@betav.comschreef in
berichtnews:uZ**************@TK2MSFTNGP02.phx.gbl. ..
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.
__________________________________
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)
---------------------------------------------------------------------------*--------------------------------------------
"AMoose" <N...@Where.comwrote in
messagenews:Cf******************************@gigan ews.com...
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?
>
>
"Miha Markic" <miha at rthand comwrote in message
>news:53**********************************@microso ft.com...
>>
>"AMoose" <N...@Where.comwrote in message
>>news:m9******************************@giganews.c om...
>>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?
Thanks,
Seth Rowe
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".
"Cor Ligthert [MVP]" <no************@planet.nlwrote in message
news:%2****************@TK2MSFTNGP03.phx.gbl...
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" <ro********@yahoo.comschreef in bericht
news:11**********************@i13g2000prf.googlegr oups.com...
On Jun 13, 2:36 pm, "Cor Ligthert [MVP]" <notmyfirstn...@planet.nl>
wrote:
>Nothing to add for me to this message.
Cor
"William (Bill) Vaughn" <billvaRemoveT...@betav.comschreef in
berichtnews:uZ**************@TK2MSFTNGP02.phx.gbl ...
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.
__________________________________
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)
---------------------------------------------------------------------------*--------------------------------------------
"AMoose" <N...@Where.comwrote in
messagenews:Cf******************************@giga news.com...
> 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?
>
>
"Miha Markic" <miha at rthand comwrote in message
>news:53**********************************@microso ft.com...
>>
>"AMoose" <N...@Where.comwrote in message
>>news:m9******************************@giganews.c om...
>>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?
Thanks,
Seth Rowe
On Jun 15, 2:18 am, "Cor Ligthert [MVP]" <notmyfirstn...@planet.nl>
wrote:
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" <rowe_em...@yahoo.comschreef in berichtnews:11**********************@i13g2000prf.g ooglegroups.com...
On Jun 13, 2:36 pm, "Cor Ligthert [MVP]" <notmyfirstn...@planet.nl>
wrote:
Nothing to add for me to this message.
Cor
"William (Bill) Vaughn" <billvaRemoveT...@betav.comschreef in
berichtnews:uZ**************@TK2MSFTNGP02.phx.gbl. ..
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 seemto
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.nettoget 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)
---------------------------------------------------------------------------*--------------------------------------------
"AMoose" <N...@Where.comwrote in
messagenews:Cf******************************@gigan ews.com...
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, lotsof
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 comwrote in message
>news:53**********************************@microso ft.com...
>"AMoose" <N...@Where.comwrote in message
>>news:m9******************************@giganews.c om...
>>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?
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
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/micro...7f3bf19?hl=en&
Cor
"rowe_newsgroups" <ro********@yahoo.comschreef in bericht
news:11**********************@w5g2000hsg.googlegro ups.com...
On Jun 15, 2:18 am, "Cor Ligthert [MVP]" <notmyfirstn...@planet.nl>
wrote:
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" <rowe_em...@yahoo.comschreef in
berichtnews:11**********************@i13g2000prf.g ooglegroups.com...
On Jun 13, 2:36 pm, "Cor Ligthert [MVP]" <notmyfirstn...@planet.nl>
wrote:
Nothing to add for me to this message.
Cor
"William (Bill) Vaughn" <billvaRemoveT...@betav.comschreef in
berichtnews:uZ**************@TK2MSFTNGP02.phx.gbl. ..
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.
__________________________________
Visitwww.hitchhikerguides.nettoget 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)
---------------------------------------------------------------------------*--------------------------------------------
"AMoose" <N...@Where.comwrote in
messagenews:Cf******************************@gigan ews.com...
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?
"Miha Markic" <miha at rthand comwrote in message
>news:53**********************************@microso ft.com...
>"AMoose" <N...@Where.comwrote in message
>>news:m9******************************@giganews.c om...
>>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?
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
When I had sent the message and I scrolled down I saw a name like Marina,
which it was.
"rowe_newsgroups" <ro********@yahoo.comschreef in bericht
news:11**********************@w5g2000hsg.googlegro ups.com...
On Jun 15, 2:18 am, "Cor Ligthert [MVP]" <notmyfirstn...@planet.nl>
wrote:
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" <rowe_em...@yahoo.comschreef in
berichtnews:11**********************@i13g2000prf.g ooglegroups.com...
On Jun 13, 2:36 pm, "Cor Ligthert [MVP]" <notmyfirstn...@planet.nl>
wrote:
Nothing to add for me to this message.
Cor
"William (Bill) Vaughn" <billvaRemoveT...@betav.comschreef in
berichtnews:uZ**************@TK2MSFTNGP02.phx.gbl. ..
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.
__________________________________
Visitwww.hitchhikerguides.nettoget 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)
---------------------------------------------------------------------------*--------------------------------------------
"AMoose" <N...@Where.comwrote in
messagenews:Cf******************************@gigan ews.com...
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?
"Miha Markic" <miha at rthand comwrote in message
>news:53**********************************@microso ft.com...
>"AMoose" <N...@Where.comwrote in message
>>news:m9******************************@giganews.c om...
>>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?
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
On Jun 15, 10:29 am, "Cor Ligthert [MVP]" <notmyfirstn...@planet.nl>
wrote:
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/micro...languages.vb/m...
Cor
"rowe_newsgroups" <rowe_em...@yahoo.comschreef in berichtnews:11**********************@w5g2000hsg.go oglegroups.com...
On Jun 15, 2:18 am, "Cor Ligthert [MVP]" <notmyfirstn...@planet.nl>
wrote:
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" <rowe_em...@yahoo.comschreef in
berichtnews:11**********************@i13g2000prf.g ooglegroups.com...
On Jun 13, 2:36 pm, "Cor Ligthert [MVP]" <notmyfirstn...@planet.nl>
wrote:
Nothing to add for me to this message.
Cor
"William (Bill) Vaughn" <billvaRemoveT...@betav.comschreef in
berichtnews:uZ**************@TK2MSFTNGP02.phx.gbl. ..
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.
__________________________________
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)
---------------------------------------------------------------------------*--------------------------------------------
"AMoose" <N...@Where.comwrote in
messagenews:Cf******************************@gigan ews.com...
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 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 comwrote in message
>news:53**********************************@microso ft.com...
>"AMoose" <N...@Where.comwrote in message
>>news:m9******************************@giganews.c om...
>>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?
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
...
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/micro...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
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.
"Cor Ligthert [MVP]" <no************@planet.nlwrote in message
news:%2****************@TK2MSFTNGP06.phx.gbl...
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/micro...7f3bf19?hl=en&
Cor
"rowe_newsgroups" <ro********@yahoo.comschreef in bericht
news:11**********************@w5g2000hsg.googlegro ups.com...
On Jun 15, 2:18 am, "Cor Ligthert [MVP]" <notmyfirstn...@planet.nl>
wrote:
>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" <rowe_em...@yahoo.comschreef in
berichtnews:11**********************@i13g2000prf. googlegroups.com...
On Jun 13, 2:36 pm, "Cor Ligthert [MVP]" <notmyfirstn...@planet.nl>
wrote:
Nothing to add for me to this message.
Cor
"William (Bill) Vaughn" <billvaRemoveT...@betav.comschreef in
berichtnews:uZ**************@TK2MSFTNGP02.phx.gbl. ..
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.
__________________________________
Visitwww.hitchhikerguides.nettoget 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)
---------------------------------------------------------------------------*--------------------------------------------
"AMoose" <N...@Where.comwrote in
messagenews:Cf******************************@gigan ews.com...
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?
"Miha Markic" <miha at rthand comwrote in message
>news:53**********************************@microso ft.com...
>"AMoose" <N...@Where.comwrote in message
>>news:m9******************************@giganews.c om...
>>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?
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
We are talking about memory, can you tell me what is the advantage of 1Gb
not used memory in a computer? Have a look in your taskmanager how many
processes there are already running.
Cor
"AMoose" <No@Where.comschreef in bericht
news:N9******************************@giganews.com ...
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.
"Cor Ligthert [MVP]" <no************@planet.nlwrote in message
news:%2****************@TK2MSFTNGP06.phx.gbl...
>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/micro...7f3bf19?hl=en&
Cor
"rowe_newsgroups" <ro********@yahoo.comschreef in bericht
news:11**********************@w5g2000hsg.googlegr oups.com...
On Jun 15, 2:18 am, "Cor Ligthert [MVP]" <notmyfirstn...@planet.nl>
wrote:
>>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" <rowe_em...@yahoo.comschreef in
berichtnews:11**********************@i13g2000prf .googlegroups.com...
On Jun 13, 2:36 pm, "Cor Ligthert [MVP]" <notmyfirstn...@planet.nl>
wrote:
Nothing to add for me to this message.
Cor
"William (Bill) Vaughn" <billvaRemoveT...@betav.comschreef in
berichtnews:uZ**************@TK2MSFTNGP02.phx.gbl ...
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.
__________________________________
Visitwww.hitchhikerguides.nettoget 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)
---------------------------------------------------------------------------*--------------------------------------------
"AMoose" <N...@Where.comwrote in
messagenews:Cf******************************@giga news.com...
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?
"Miha Markic" <miha at rthand comwrote in message
>news:53**********************************@microso ft.com...
>"AMoose" <N...@Where.comwrote in message
>>news:m9******************************@giganews.c om...
>>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?
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
I think you brought up the subject of dispose taking up cpu cycles. Didn't
you? Let me see "What bothers me that people thinks that doing an extra
proces as dispose takes no time. Every process takes at least one cycle."
Yup you did.
It's not my personal computer that I write applications for. If I look at my
servers during the regular business hours most of the servers memory is
being used. So I have to worry about memory allocation and cpu utilization.
Do you write scalable server applications that service large companies and
their customers or desktop applications?
"Cor Ligthert [MVP]" <no************@planet.nlwrote in message
news:eu**************@TK2MSFTNGP02.phx.gbl...
We are talking about memory, can you tell me what is the advantage of 1Gb
not used memory in a computer? Have a look in your taskmanager how many
processes there are already running.
Cor
"AMoose" <No@Where.comschreef in bericht
news:N9******************************@giganews.com ...
>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.
"Cor Ligthert [MVP]" <no************@planet.nlwrote in message
news:%2****************@TK2MSFTNGP06.phx.gbl...
>>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/micro...7f3bf19?hl=en&
Cor
"rowe_newsgroups" <ro********@yahoo.comschreef in bericht
news:11**********************@w5g2000hsg.googleg roups.com...
On Jun 15, 2:18 am, "Cor Ligthert [MVP]" <notmyfirstn...@planet.nl>
wrote:
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" <rowe_em...@yahoo.comschreef in
berichtnews:11**********************@i13g2000pr f.googlegroups.com...
On Jun 13, 2:36 pm, "Cor Ligthert [MVP]" <notmyfirstn...@planet.nl>
wrote:
Nothing to add for me to this message.
Cor
"William (Bill) Vaughn" <billvaRemoveT...@betav.comschreef in
berichtnews:uZ**************@TK2MSFTNGP02.phx.gb l...
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.
__________________________________
Visitwww.hitchhikerguides.nettoget 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)
---------------------------------------------------------------------------*--------------------------------------------
"AMoose" <N...@Where.comwrote in
messagenews:Cf******************************@gig anews.com...
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?
"Miha Markic" <miha at rthand comwrote in message
>news:53**********************************@microso ft.com...
>"AMoose" <N...@Where.comwrote in message
>>news:m9******************************@giganews.c om...
>>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?
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
AMoose,
As long as it is not done by Citrix or something like that, is on a Server
dotNet not involved.
SQLServer, IIS, SharePoint, BizServer etc are the things that are running on
those places. The desktop (as well in Citrix by the way) is the place where
the dotNet process is running.
We are not talking here about Unix systems or other mainframes.
Cor
"AMoose" <No@Where.comschreef in bericht
news:So******************************@giganews.com ...
>I think you brought up the subject of dispose taking up cpu cycles. Didn't
you? Let me see "What bothers me that people thinks that doing an extra
proces as dispose takes no time. Every process takes at least one cycle."
Yup you did.
It's not my personal computer that I write applications for. If I look at
my servers during the regular business hours most of the servers memory is
being used. So I have to worry about memory allocation and cpu
utilization. Do you write scalable server applications that service large
companies and their customers or desktop applications?
"Cor Ligthert [MVP]" <no************@planet.nlwrote in message
news:eu**************@TK2MSFTNGP02.phx.gbl...
>We are talking about memory, can you tell me what is the advantage of 1Gb
not used memory in a computer? Have a look in your taskmanager how many
processes there are already running.
Cor
"AMoose" <No@Where.comschreef in bericht
news:N9******************************@giganews.co m...
>>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.
"Cor Ligthert [MVP]" <no************@planet.nlwrote in message
news:%2****************@TK2MSFTNGP06.phx.gbl.. .
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/micro...7f3bf19?hl=en&
Cor
"rowe_newsgroups" <ro********@yahoo.comschreef in bericht
news:11**********************@w5g2000hsg.google groups.com...
On Jun 15, 2:18 am, "Cor Ligthert [MVP]" <notmyfirstn...@planet.nl>
wrote:
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" <rowe_em...@yahoo.comschreef in
berichtnews:11**********************@i13g2000p rf.googlegroups.com...
On Jun 13, 2:36 pm, "Cor Ligthert [MVP]" <notmyfirstn...@planet.nl>
wrote:
>
>
>
Nothing to add for me to this message.
>
Cor
>
"William (Bill) Vaughn" <billvaRemoveT...@betav.comschreef in
berichtnews:uZ**************@TK2MSFTNGP02.phx.g bl...
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.
__________________________________
Visitwww.hitchhikerguides.nettoget 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)
>
>
>
>
>
---------------------------------------------------------------------------*--------------------------------------------
>
"AMoose" <N...@Where.comwrote in
messagenews:Cf******************************@gi ganews.com...
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?
>
"Miha Markic" <miha at rthand comwrote in message
>news:53**********************************@microso ft.com...
>
>"AMoose" <N...@Where.comwrote in message
>>news:m9******************************@giganews.c om...
>>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?
>
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
Little correction.
I was talking here about Windows applications, for ASPNET or SharePoint
applications the Server is the place where the middle tiers goes, however
that is serving an unknown users at the same time and needs therefore
forever a high reserve from resources. But in that case has the server in my
idea to be seen as the user computer although that is serves an unknown
amount of users at the same time.
Cor
"Cor Ligthert [MVP]" <no************@planet.nlschreef in bericht
news:OZ**************@TK2MSFTNGP04.phx.gbl...
AMoose,
As long as it is not done by Citrix or something like that, is on a Server
dotNet not involved.
SQLServer, IIS, SharePoint, BizServer etc are the things that are running
on those places. The desktop (as well in Citrix by the way) is the place
where the dotNet process is running.
We are not talking here about Unix systems or other mainframes.
Cor
"AMoose" <No@Where.comschreef in bericht
news:So******************************@giganews.com ...
>>I think you brought up the subject of dispose taking up cpu cycles. Didn't
you? Let me see "What bothers me that people thinks that doing an extra
proces as dispose takes no time. Every process takes at least one cycle."
Yup you did.
It's not my personal computer that I write applications for. If I look at
my servers during the regular business hours most of the servers memory
is being used. So I have to worry about memory allocation and cpu
utilization. Do you write scalable server applications that service large
companies and their customers or desktop applications?
"Cor Ligthert [MVP]" <no************@planet.nlwrote in message
news:eu**************@TK2MSFTNGP02.phx.gbl...
>>We are talking about memory, can you tell me what is the advantage of
1Gb not used memory in a computer? Have a look in your taskmanager how
many processes there are already running.
Cor
"AMoose" <No@Where.comschreef in bericht
news:N9******************************@giganews.c om...
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.
"Cor Ligthert [MVP]" <no************@planet.nlwrote in message
news:%2****************@TK2MSFTNGP06.phx.gbl. ..
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/micro...7f3bf19?hl=en&
>
Cor
>
>
>
>
>
"rowe_newsgroups" <ro********@yahoo.comschreef in bericht
news:11**********************@w5g2000hsg.googl egroups.com...
On Jun 15, 2:18 am, "Cor Ligthert [MVP]" <notmyfirstn...@planet.nl>
wrote:
>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" <rowe_em...@yahoo.comschreef in
>berichtnews:11**********************@i13g2000 prf.googlegroups.com...
>On Jun 13, 2:36 pm, "Cor Ligthert [MVP]" <notmyfirstn...@planet.nl>
>wrote:
>>
>>
>>
Nothing to add for me to this message.
>>
Cor
>>
"William (Bill) Vaughn" <billvaRemoveT...@betav.comschreef in
berichtnews:uZ**************@TK2MSFTNGP02.phx. gbl...
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.
__________________________________
Visitwww.hitchhikerguides.nettoget 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)
>>
>>
>>
>>
>>
>>
---------------------------------------------------------------------------*--------------------------------------------
>>
"AMoose" <N...@Where.comwrote in
messagenews:Cf******************************@g iganews.com...
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?
>>
"Miha Markic" <miha at rthand comwrote in message
>news:53**********************************@microso ft.com...
>>
>"AMoose" <N...@Where.comwrote in message
>>news:m9******************************@giganews.c om...
>>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?
>>
>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
>
>
I develop .NET applications for servers. This means ASP.NET, SharePoint, Web
Services and custom middle tier services. These serve a large number of
users (usually unknown or guessetimated) as well as other requests from
other applications for integration. These have to support a large number of
users and applications with limited resources (memory and cpu).
I cannot have a lazy attitude when it comes to memory or cpu, these
resources must be thought about when I develop these applications. Hence my
concern over calling dispose or not calling dispose. Again, I have seen
problems arise when developers do not call dispose but have never seen any
problems when developers do call dispose, whether it does something or not.
Not only that, but I'm a consultant who comes in builds these things and
leaves. When I see a class implement dispose, I could pull out reflector and
take a peek inside to determine if I should call dipose or not, but what
guarantee is there that this class won't implement some clean up code in
dispose when I leave? I don't, and I'm not just talking about MS classes,
I'm talking about third party classes as well or other classes that I don't
have the source code. So I'd rather take the proactive stance, call dispose
just case in the future something changes, and the fact that I won't be
there to handle it for my client. That isn't the only problem in this
scenario either, if my client saw me poking around classes trying to
determine to call dispose or not, and they are paying me lots of money per
hour, they wouldn't use me as a consultant in the future. In other words if
I see a class implement dispose, I call dispose and move on to the real
problems my client has me there for.
Does this make any sense?
"Cor Ligthert [MVP]" <no************@planet.nlwrote in message
news:Od**************@TK2MSFTNGP05.phx.gbl...
Little correction.
I was talking here about Windows applications, for ASPNET or SharePoint
applications the Server is the place where the middle tiers goes, however
that is serving an unknown users at the same time and needs therefore
forever a high reserve from resources. But in that case has the server in
my idea to be seen as the user computer although that is serves an unknown
amount of users at the same time.
Cor
"Cor Ligthert [MVP]" <no************@planet.nlschreef in bericht
news:OZ**************@TK2MSFTNGP04.phx.gbl...
>AMoose,
As long as it is not done by Citrix or something like that, is on a
Server dotNet not involved.
SQLServer, IIS, SharePoint, BizServer etc are the things that are running
on those places. The desktop (as well in Citrix by the way) is the place
where the dotNet process is running.
We are not talking here about Unix systems or other mainframes.
Cor
"AMoose" <No@Where.comschreef in bericht
news:So******************************@giganews.co m...
>>>I think you brought up the subject of dispose taking up cpu cycles.
Didn't you? Let me see "What bothers me that people thinks that doing an
extra proces as dispose takes no time. Every process takes at least one
cycle." Yup you did.
It's not my personal computer that I write applications for. If I look
at my servers during the regular business hours most of the servers
memory is being used. So I have to worry about memory allocation and
cpu utilization. Do you write scalable server applications that service
large companies and their customers or desktop applications?
"Cor Ligthert [MVP]" <no************@planet.nlwrote in message
news:eu**************@TK2MSFTNGP02.phx.gbl...
We are talking about memory, can you tell me what is the advantage of
1Gb not used memory in a computer? Have a look in your taskmanager how
many processes there are already running.
Cor
"AMoose" <No@Where.comschreef in bericht
news:N9******************************@giganews. com...
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.
>
>
"Cor Ligthert [MVP]" <no************@planet.nlwrote in message
news:%2****************@TK2MSFTNGP06.phx.gbl.. .
>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/micro...7f3bf19?hl=en&
>>
>Cor
>>
>>
>>
>>
>>
>"rowe_newsgroups" <ro********@yahoo.comschreef in bericht
>news:11**********************@w5g2000hsg.goog legroups.com...
>On Jun 15, 2:18 am, "Cor Ligthert [MVP]" <notmyfirstn...@planet.nl>
>wrote:
>>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" <rowe_em...@yahoo.comschreef in
>>berichtnews:11**********************@i13g200 0prf.googlegroups.com...
>>On Jun 13, 2:36 pm, "Cor Ligthert [MVP]" <notmyfirstn...@planet.nl>
>>wrote:
>>>
>>>
>>>
>Nothing to add for me to this message.
>>>
>Cor
>>>
> "William (Bill) Vaughn" <billvaRemoveT...@betav.comschreef in
>berichtnews:uZ**************@TK2MSFTNGP02.phx .gbl...
> 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.
> __________________________________
> Visitwww.hitchhikerguides.nettoget 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)
>>>
>>>
>>>
>>>
>>>
>>>
>>>
> ---------------------------------------------------------------------------*--------------------------------------------
>>>
> "AMoose" <N...@Where.comwrote in
>messagenews:Cf******************************@ giganews.com...
> 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?
>>>
> "Miha Markic" <miha at rthand comwrote in message
> >news:53**********************************@microso ft.com...
>>>
> >"AMoose" <N...@Where.comwrote in message
> >>news:m9******************************@giganews.c om...
> >>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?
>>>
>>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
>>
>>
>
>
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Eva |
last post by:
Hi
i am trying to insert a new row into one of my datatabels that i have in my dataset when a button is clicked. here is my code
Dim ClientInsRow As DataRow = dtClient.NewRo
...
|
by: aiKeith |
last post by:
I have a really stupid problem I'm hoping to get help with.
The problem occurs if I delete rows from a dynamically built datatable.
ie:
CreateDataTable(); // creates the structure of the...
|
by: faktujaa |
last post by:
Hi All,
A small confusion. I have defined a connection class that has
System.Data.IDbConnection as a member variable and implements IDisposable
interface. I have implemented Dispose method to call...
|
by: RiteshDotNet |
last post by:
..net Frame work
1. Dispose Method what it does ?
A. who its call / when it calls ?
B. Is it fire automatically ?
c. When dispose method is call what it does ?
D. Release a Object from memory or...
|
by: Sam Sungshik Kong |
last post by:
Hello!
A disposable object's Dispose() method can be called either explicitly by
the programmer or implicitly during finalization.
If you call Dispose, the unmanaged resources are released...
|
by: Raymond Lewallen |
last post by:
Which would be the proper way or the reason for using any of the following
or combinations of the following? These are the 3 ways I've figured I can
do what I want to do, I just don't know which...
|
by: not_a_commie |
last post by:
Are there any tools available to track down IDisposable objects that
don't have a call to Dispose? I'm thinking this can be done with
static code analysis. If the object is created inside a method,...
|
by: jeevankodali |
last post by:
Hi
I have a multi threaded ftp server. 2 days back it threw an exception:
System.IO.IOException: The specified network name is no longer
available.
at System.IO.__Error.WinIOError(Int32...
|
by: Frank Hauptlorenz |
last post by:
Hello,
I recognized some days ago, that returning a DataTable blocks my
WCF-Service. Is this a known bug?
If I add this table to a new DataSet() and return this, it works.
Thank you,
Frank
|
by: CloudSolutions |
last post by:
Introduction:
For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
| |
