The garbage man in the .Net framework is weird like that. even if the object has been rendered un-referenced, there is no guarantee when, or in what order the garbage collector will come for destruction. To my understanding, you can explicitly call to destroy the objects and then take them out of the queue to be destroyed (but perhaps this would only have an effect on the order they are destroyed - and not the time).
Please correct me if I am wrong ~ David J. McKenzie On Tue, Sep 28, 2010 at 9:04 AM, Stephen Russell <[email protected]>wrote: > On Mon, Sep 27, 2010 at 12:23 PM, BB <[email protected]> wrote: > > I know this. > > Garbage have no to think that this object can be useful for me because > > it exits from the scope. > > Infact, It destroy the object if it does not cointain event > > declaration. > > I have to worry because it is not useful but it get memory > > full...untill application close! > > oEl = nothing is just a verify, but garbage would have to destroy it > > also without it if the event is not assigned, OR NOT? > > Why it doesnt treat event as the other property?? And overall, is > > there a way to free the object that has some event declared? > > Maybe the answare is that the event keep an handler of the object that > > declare and create it. But when this object is finalized the event and > > is handler must be free, or we get a strange situation -.- > ------------------- > > You are confusing the line in code > oEI = nothing > and the action of garbage collection. > > Think more along the lines of > oEI = nothing is just like the low gas indicator light on your > dashboard for your car. That indicator reminds you to get gas soon > but you can still drive for 30 min to one hour. Sometime between the > 30 ->60 min you will run out of gas and it varies by how you are > currently driving. > > So too is the M$ Windows server. It will vary depending on load and > applications running. > > You can loop through a class that instantiates an object and destroys > it. Sure you could see memory diminish because the server felt no > need to reclaim that recoverable memory. > > As I stated the first time you are in a M$ "time" experience. Your > code stated to drop that memory usage but the server doesn't need to > follow through yet. > > > > On 27 Set, 16:07, Stephen Russell <[email protected]> wrote: > >> On Sat, Sep 25, 2010 at 4:07 AM, BB <[email protected]> wrote: > >> > The problem is that I don't attach anything. > >> > Try this test code pls, so I will be sure that I am not crazy ^^... > >> > >> > Public Class CMyClass > >> > Inherits Object > >> > Private fPropertyOne As String > >> > Private fPropertyTwo As Integer > >> > Public Event OnSomeEvent(ByRef vSender As Object) > >> > End Class > >> > >> > Private Sub btn1_Click(ByVal sender As System.Object, ByVal e As > >> > System.EventArgs) Handles btn1.Click > >> > >> > Dim i As Integer > >> > For i = 0 To 1000 > >> > Dim oEl As New CMyClass() > >> > Console.WriteLine("element created " & > >> > GC.GetTotalMemory(True)) > >> > oEl = nothing > >> > Console.WriteLine("element after destroying " & > >> > GC.GetTotalMemory(True)) > >> > Next > >> > End Sub > >> > End Class > >> > >> --------------------- > >> > >> oEI = nothing is just a marker for the garbage collector to use in the > >> future. It is not going to be performed on your time and if you call > >> it to be performed your performance will get worse. > >> > >> Think of it as "You are on M$ time" They will decide what is good for > >> you and you need not worry about it. > >> > >> ;-> > >> > >> -- > >> Stephen Russell > >> > >> Sr. Production Systems Programmer > >> CIMSgts > >> > >> 901.246-0159 cell > > > > -- > Stephen Russell > > Sr. Production Systems Programmer > CIMSgts > > 901.246-0159 cell >
