Garbage collection supression

[Paul.Lee.1971]

Hi everyone,
A program that I'm helping to code seems to slow down drastically
during initialisation, and looking at the profiling graph, it seems to
be the garbage collector thats slowing things down. I must point out
that a heck of a lot of data are being read in and manipulated, and I
was wondering if there were any metrics to show much of a performance
hit is occurring during the initialisation? If it turns out that the
GC is having a bad effect on the program, is there a way to suppress
the operation of the GC (although this does sound like a very bad idea
IMHO)

TIA

Paul

 

[DeveloperX]

Hi everyone,
A program that I'm helping to code seems to slow down drastically
during initialisation, and looking at the profiling graph, it seems to
be the garbage collector thats slowing things down. I must point out
that a heck of a lot of data are being read in and manipulated, and I
was wondering if there were any metrics to show much of a performance
hit is occurring during the initialisation? If it turns out that the
GC is having a bad effect on the program, is there a way to suppress
the operation of the GC (although this does sound like a very bad idea
IMHO)

TIA

Paul
--http://www.paullee.com

Afraid not. Are you creating and dumping large numbers of objects? If
so, could you create a pool of objects and reuse them for example?

 

[Paul.Lee.1971]

Afraid not. Are you creating and dumping large numbers of objects? If
so, could you create a pool of objects and reuse them for example?

Hi,
Yes that is one option we could look at. I'm just thinking about the
hit on program speed due to the GC running.
We have about 0.6MB reclaimed in a second at one point, and then, 3 MB
in a second a little later on. This must impact
the running speed?

Paul

 

[Jon Skeet [C# MVP]]

If you use objects that implement the IDisposable interface, you should
be careful to always call the Dispose method when you are done with
them. Objects that implement IDisposable has a finalizer as backup for
the Dispose method, which means that they are references from the
finalizer queue.

Just to be clear - *some* types which implement IDisposable also have a
finalizer. It's by no means a requirement, and many types which
implement IDisposable neither have nor need a finalizer. You should
still call Dispose on them though

 

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

Just to be clear - *some* types which implement IDisposable also have a
finalizer. It's by no means a requirement, and many types which
implement IDisposable neither have nor need a finalizer. You should
still call Dispose on them though

Thanks for the correction. The recommended implementation of
IDisposable includes using a finalizer, so I thought that most classed
would follow that.

 

[Jon Skeet [C# MVP]]

Thanks for the correction. The recommended implementation of
IDisposable includes using a finalizer, so I thought that most classed
would follow that.

That should only be the recommendation *if* the type directly contains
unmanaged resources. If it only contains references to other types
which contain unmanaged resource (e.g. it has a reference to a stream)
then you shouldn't have a finalizer.

 

[Barry Kelly]

Thanks for the correction. The recommended implementation of
IDisposable includes using a finalizer,

You may have been looking at the recommended implementation of a
*finalizable object&, which should include an IDisposable
implementation.

The converse is not necessarily true.

-- Barry

 

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

You may have been looking at the recommended implementation of a
*finalizable object&, which should include an IDisposable
implementation.

The converse is not necessarily true.

-- Barry

No, I have been looking at the recommended implementation of the
IDisposable interface:

http://msdn2.microsoft.com/en-us/library/system.idisposable.aspx