Michael:

At the application startup I create the objects that I need. For example, my app handles messages from monitoring devices that come in over telephone lines. Each message is from a single client. I count the number of telephone lines connected to my communication server and instantiate one client object for each line (since only one message can be handled by one telephone line at a time). After each session, instead of releasing the client object, I leave it available for the next message on that line. When the message comes in I simply change the properties to reflect the different state of the "new" object.

Rick Grinter
>Rick,
>
>What do you mean by "re-using" objects ?
>
>Michel.
>
>=================== Your original message follows ================
>
>>>Rick,
>>>
>>>With a clearer head I have found that the documentation (book - VFP 5 "Developer's Guide" or VFP 6 "Programmer's Guide") is correct with regard to 'dangling references' to an object causing it to remain in memory. Note too that RELEASE gives no indication that this is the case, leaving one to presume that it functioned as expected.
>>>
>>>The short program below exhibits, on my 64 meg Pentium 233 and with the FOR loop set to do 99 iterations (not 3 as currently coded) fails with a "There is not enough memory..." error on the 88th CreateObject. This is, I would call it, a 'memory leak' within VFP.
>>>
>>>The run with 99 also runs REAL SLOW after the 8th or 9th CreateObject. Lots of hard-drive activity too, suggesting that SWAP is used from that point on.
>>>
>>>A second run, typing RESUME to end the first run and changing the FOR loop to execute only 3 times, shows the starting user-object memory usage to be 44,404,408!!! The 'cost of Xx' also shows to be around 9,000 bytes as opposed to just over 500,000 in the first run.
>>>
>>>I cannot explain this at all.
>>>
>>>Finally, on ending VFP, the hard drive went crazily for about a minute, presumably clearing the SWAP file.
>>>
>>>But I do feel that this proves conclusively that a 'dangling reference' *DOES* result in slowness, possibly leading to an out-of-memory condition UNDER THE RIGHT CIRCUMSTANCES.
>>>
>>>Here's the code, again not nicely formatted for my lack of capability to do so for this medium:
>>>
>>>clear
>>>clear all
>>>
>>>BaseStartMsg= "Starting user-object memory use is "
>>>AfterXCreatedMsg= "user-object mem. right after creating form object "
>>>CostOfXMsg= "So cost in memory of "
>>>AfterDangleMsg= "After making a (later) dangling reference to "
>>>CostOfYCreated= "And the memory cost of "
>>>AfterXReleased= "Size now occupied by program after releasing "
>>>
>>>Base_At_Start_ln= VAL(sys(1016))
>>>
>>>? BaseStartMsg, base_at_start_ln
>>>? " "
>>>
>>>* Changing the FOR loop to do 99 iterations gave, on my 64meg machine,
>>>* a "There is not enough memory to complete this operation", which was
>>>* the "this.Tag = replicate. . ." command in cForm.Init, after the 87th Xx object
>>>* was created (ie on the 88th object) [ VFP 6.0 in virgin state ]
>>>
>>>* CURIOSITY: A second run of the program (after changing the loop to run 3 times
>>>* and executed right after completion of the first run after resume of
>>>* SUSPEND) runs OK but has the following anomolies:
>>>* a) Starting user-object memory use is 44,404,408 bytes despite the
>>>* program having a CLEAR ALL at the start;
>>>* b) Cost of Xx shows to be around 9,000 bytes (in the first run,
>>>* done right after starting VFP, it averaged 500,000+ bytes).
>>>* TO ME THIS LEADS TO SERIOUS QUESTIONS AS TO JUST WHAT SYS(1016) REPORTS.
>>>
>>>FOR LL = 1 to 03 step 1
>>>
>>> LC=ltrim(str(LL,2,0))
>>>
>>> Size_at_start_of_loop_ln= val(sys(1016))
>>>
>>> x&LC. = createobject( "cForm" )
>>>
>>> Right_After_X&LC._Created_ln= val(sys(1016))
>>>
>>> Cost_of_X&LC._ln= ;
>>> Right_After_X&LC._Created_ln - Size_at_start_of_loop_ln
>>>
>>> ? AfterXCreatedMsg + "X&LC.", VAL(sys(1016))
>>> ? CostOfXMsg + "X&LC.", Cost_of_X&LC._ln
>>>
>>> y&LC.= x&LC..txtBox
>>>
>>> After_Y&LC._referencing_X&LC._ln= val(sys(1016))
>>>
>>> Cost_of_Y&LC._ln= ;
>>> After_Y&LC._referencing_X&LC._ln - Right_After_X&LC._Created_ln
>>>
>>> ? AfterDangleMsg + "X&LC.", val(sys(1016))
>>> ? CostOfYCreated + "Y&LC.", Cost_of_Y&LC._ln
>>>
>>> release x&LC.
>>>
>>> After_X&LC._is_Released_ln= val(sys(1016))
>>>
>>> ? "Memory cost of Y&LC. after X&LC. released", ;
>>> after_X&LC._is_released_ln - After_Y&LC._referencing_X&LC._ln
>>> ? " "
>>> ? AfterXReleased + "X&LC.", ;
>>> after_X&LC._is_released_ln - base_at_start_ln
>>> ? " "
>>>
>>>ENDFOR
>>>
>>>suspend && On this SUSPEND, do a DISP MEMO in Command Window
>>>
>>>CLEAR CLASS cForm && attempt to address 2nd run anomolies
>>>CLEAR PROGRAM && attempt to address 2nd run anomolies
>>>
>>>define class cForm as Form
>>>
>>> ADD OBJECT txtBOX AS TEXTBOX
>>>
>>> procedure Init
>>> this.Tag = replicate( "abcde", 100000 )
>>> this.Visible = .F.
>>> endproc
>>>
>>>enddefine
>>>
>>>Cheers,
>>>
>>>Jim N
>>Jim:
>>
>>Wow! Sounds like while I was out "trick-or-treating" last night you were busy with that coffee pot. Thanks for all your valuable input. Essentially you have gone through the same iteration that I did when I first discovered my app slowing down. First I put SYS(1016) calculations throughout my code and then step by step removed CREATEOBJECT() or AddObject(). You are correct that SYS(1016) reports can be volatile -- but there is an unmistakeable diminuation of available memory as objects are created and released. As I said earlier, I have "solved" the problem by reuseing objects -- sort of like reuesing records in a .DBF. SYS(1016) is still moving up and down (at least there is downward movement) and available memory is much more consistent now.
>>
>>Again, thanks. I need to study all your messages and code more carefully, but it helps my sanity if nothing else to see someone else has replicated the problem.
>>
>>Rick Grinter