when to dispose a datatable?

  • Thread starter Thread starter Smokey Grindle
  • Start date Start date
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 said:
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 said:
Seth,

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

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

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

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

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

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

Cor





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

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

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

Cor

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



Nothing to add for me to this message.

Cor

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

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

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
INETA Speaker
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no
rights.
__________________________________
Visitwww.hitchhikerguides.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)



---------------------------------------------------------------------------­--------------------------------------------

messageTrue.

But its been my experience that the GC does most of its cleanup
when
there
is some level of memory pressure, not when "there is nothing 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 com> wrote in message

Cor,

Can you provide a link to documentation where it states that the
GC
does
cleanup when there is nothing else to be done?

GC does cleanup when it decides to do it. It has a built in smart
scheduler that should do in most cases.
--
Miha Markic [MVP C#, INETA Country Leader for Slovenia]
RightHand .NET consulting & developmentwww.rthand.com
Blog:http://cs.rthand.com/blogs/blog_with_righthand/

Nothing to add for me to this message.

Cor, what about Bill's first sentence:

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

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

Are you confused about something Cor?

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 said:
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 said:
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 said:
Seth,

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

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

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

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

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

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

Cor





"rowe_newsgroups" <[email protected]> schreef in bericht
On Jun 15, 2:18 am, "Cor Ligthert [MVP]" <[email protected]>
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" <[email protected]> schreef in
berichtOn Jun 13, 2:36 pm, "Cor Ligthert [MVP]" <[email protected]>
wrote:



Nothing to add for me to this message.

Cor

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

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

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
INETA Speaker
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no
rights.
__________________________________
Visitwww.hitchhikerguides.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)




---------------------------------------------------------------------------­--------------------------------------------

messageTrue.

But its been my experience that the GC does most of its cleanup
when
there
is some level of memory pressure, not when "there is nothing 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 com> wrote in message

Cor,

Can you provide a link to documentation where it states that
the GC
does
cleanup when there is nothing else to be done?

GC does cleanup when it decides to do it. It has a built in
smart
scheduler that should do in most cases.
--
Miha Markic [MVP C#, INETA Country Leader for Slovenia]
RightHand .NET consulting & developmentwww.rthand.com
Blog:http://cs.rthand.com/blogs/blog_with_righthand/

Nothing to add for me to this message.

Cor, what about Bill's first sentence:

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

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

Are you confused about something Cor?

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 said:
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 said:
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 said:
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.


Seth,

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

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

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

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

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

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

Cor





"rowe_newsgroups" <[email protected]> schreef in bericht
On Jun 15, 2:18 am, "Cor Ligthert [MVP]" <[email protected]>
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" <[email protected]> schreef in
berichtOn Jun 13, 2:36 pm, "Cor Ligthert [MVP]" <[email protected]>
wrote:



Nothing to add for me to this message.

Cor

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

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

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
INETA Speaker
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers
no
rights.
__________________________________
Visitwww.hitchhikerguides.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)





---------------------------------------------------------------------------­--------------------------------------------

messageTrue.

But its been my experience that the GC does most of its cleanup
when
there
is some level of memory pressure, not when "there is nothing
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 com> wrote in message

Cor,

Can you provide a link to documentation where it states that
the GC
does
cleanup when there is nothing else to be done?

GC does cleanup when it decides to do it. It has a built in
smart
scheduler that should do in most cases.
--
Miha Markic [MVP C#, INETA Country Leader for Slovenia]
RightHand .NET consulting & developmentwww.rthand.com
Blog:http://cs.rthand.com/blogs/blog_with_righthand/

Nothing to add for me to this message.

Cor, what about Bill's first sentence:

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

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

Are you confused about something Cor?

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 said:
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 said:
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 said:
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" <[email protected]> schreef in bericht
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.


Seth,

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

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

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

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

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

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

Cor





"rowe_newsgroups" <[email protected]> schreef in bericht
On Jun 15, 2:18 am, "Cor Ligthert [MVP]" <[email protected]>
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" <[email protected]> schreef in
berichtOn Jun 13, 2:36 pm, "Cor Ligthert [MVP]" <[email protected]>
wrote:



Nothing to add for me to this message.

Cor

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

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

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
INETA Speaker
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers
no
rights.
__________________________________
Visitwww.hitchhikerguides.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)






---------------------------------------------------------------------------­--------------------------------------------

messageTrue.

But its been my experience that the GC does most of its cleanup
when
there
is some level of memory pressure, not when "there is nothing
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 com> wrote in message

Cor,

Can you provide a link to documentation where it states that
the GC
does
cleanup when there is nothing else to be done?

GC does cleanup when it decides to do it. It has a built in
smart
scheduler that should do in most cases.
--
Miha Markic [MVP C#, INETA Country Leader for Slovenia]
RightHand .NET consulting & developmentwww.rthand.com
Blog:http://cs.rthand.com/blogs/blog_with_righthand/

Nothing to add for me to this message.

Cor, what about Bill's first sentence:

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

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

Are you confused about something Cor?

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 said:
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 said:
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 said:
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?


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" <[email protected]> schreef in bericht
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.


Seth,

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

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

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

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

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

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

Cor





"rowe_newsgroups" <[email protected]> schreef in bericht
On Jun 15, 2:18 am, "Cor Ligthert [MVP]" <[email protected]>
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" <[email protected]> schreef in
berichtOn Jun 13, 2:36 pm, "Cor Ligthert [MVP]" <[email protected]>
wrote:



Nothing to add for me to this message.

Cor

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

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

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
INETA Speaker
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers
no
rights.
__________________________________
Visitwww.hitchhikerguides.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)







---------------------------------------------------------------------------­--------------------------------------------

messageTrue.

But its been my experience that the GC does most of its
cleanup when
there
is some level of memory pressure, not when "there is nothing
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 com> wrote in message

Cor,

Can you provide a link to documentation where it states that
the GC
does
cleanup when there is nothing else to be done?

GC does cleanup when it decides to do it. It has a built in
smart
scheduler that should do in most cases.
--
Miha Markic [MVP C#, INETA Country Leader for Slovenia]
RightHand .NET consulting & developmentwww.rthand.com
Blog:http://cs.rthand.com/blogs/blog_with_righthand/

Nothing to add for me to this message.

Cor, what about Bill's first sentence:

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

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

Are you confused about something Cor?

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
 
Back
Top