Quote
The solution to the problem was a call to Panel.Dispose. IOW, leaving
the calling of IDisposable.Dispose for the Panel to the GC (as opposed
to explicitly calling it ourselves) was what caused the increasing
delay.
Hi David,
You created a control on demand and nether disposed it?
Well, there is this urban legand that GC will call Dispose. It won't do
that! What might happen is, that the class has a VB-monk safety mechanism
to call Dispose in the finalizer. Since GC runs in it is own Thread this
requires the finalizer to be synchronized. I don't have to mention that
this kind of thing can get pretty slow.
If something is an IDisposable, the first thing to do is running Reflector
and check if it really doesn't contain any unmanaged stuff. Only if you
can verify this you don't have to dispose it explicitly.
This is IMHO part of .Net 101 and most .Net languages have an using
statement to make this pretty nice to read/write.
(btw , using would be a great addition to native Delphi, too ;-) )
using (YourDialogPanel dialog = new YourDialogPanel(referenceToYourForm))
{
if (dialog.ShowDialog() == DialogResult.OK)
DoSomething...
}
Where you would use ShowDialog to fake the behaviour of a "real" dialog.
My point was, that this was no case of some esoteric strangeness in GC,
but a completely deterministic MemLeak or the reason why finalizers
usually suck. ;-)
btw: It was said that GC in .Net 3.0 can handle unmanaged stuff inside
managed processes as well. Let's see if this is going to happen or even
desirable. ;)
--- posted by geoForum on
delphi.newswhat.com