In a sub with object variables (ranges, etc) not declared as Static, what is the point of setting them to Nothing prior to completion? When the subroutine terminates and the variables go out of scope, do they not implicitly release memory?
Releasing Object Variables
-
-
-
Re: Releasing Object Variables
Good question.
I don't think you need to other than when using data objects like ADO connections and recordsets where Microsoft specifically suggests it and memory leaks lurk. I have seen applications (Access, Outlook ...) created on the fly can remain in memory until you kill them.
I got in to the habit of doing it with any referenced object (objects not part of the current application : FSO, Dictionary ... ) but now I think about it I don't know why I bother.
On the other hand it does not do any harm ? I guess it becomes a matter of style. Release the object from memory when you've finished with it rather than leaving up to the garbage collector to decide when to do it ?
Carl
-
Re: Releasing Object Variables
As I understand it, the memory is supposed to be released, but isn't always. Therefore, to be on the safe side, set the variables to nothing. I don't know how frequent Excel forgets to automatically release the memory, or even if it's still a problem with recent versions of Excel.
-
Re: Releasing Object Variables
I just searched around a bit
A long discussion here http://blogs.msdn.com/ericlippert/ar…/28/122259.aspx
A explanation of the application problem here http://www.tushar-mehta.com/excel/vba/xl_doesnt_quit/
My conclusion after reading all that is : -
Do not bother to set an object to nothing unless :
1. It is a data access object ADO or DAO connection, recordset, command ...
2. It is a MS Application using late binding (Word, PP, Access ...)
3. When you specifically want to release memory or release objects in a particular order. -
Re: Releasing Object Variables
Carlmack, thank you. Those are very informative links, and I your conclusions summarize those authors' perspectives well.
Derk, thank you as well. Can you think of an easy way to test if some weighty object gets released?
Does this apply only to objects, or can it extend to arrays? I've never seen anyone bother to erase an array before terminating ...
-
-
Re: Releasing Object Variables
As a Rule; Anything that your program has to acquire via CreateObject, Set, Get etc you should release.
Even if the documentation states that Windows takes care of releasing the resource used by a process when it exits.The cost to you is just a few lines of code, BUT, NOT having resorces released properly can
be detrimental to the running performance.On the lower level API programing this is very true.
In APIs that Create, open, extract etc it is IMPORTANT that you use it's corresponding "Release" API to release resources to it. eg using the API CopyEnhMetaFileA, Windows keeps a record of GDI objects on a per-process basis, only the application that created the GDI object is able to use the corresponding GDI functions with it or remove it from the system eg delete it.
The API we need to ALWAYS USE for this is DeleteEnhMetaFile.So if you used;
LoadBitmapA > then you need to use DeleteObject to release resources
CreateBitmap > DeleteObject
CreateSolidBrush > DeleteObject
CreateCursor > DestroyCursor
CreateCompatibleDC > DeleteDC
GetDC > ReleaseDC
CreateFontA > DeleteObject
CreateIcon > DestroyIcon
ExtractIconA > DestroyIcon
CreateMetaFileA > CloseMetaFile
CopyMetaFileA > DeleteMetaFileSo to be on the safe side I always Set to nothing
-
Re: Releasing Object Variables
Isn't simply a case of all variables are released dependent on their dimmensioned level?
-
Re: Releasing Object Variables
Quote
Does this apply only to objects, or can it extend to arrays?I would say it's more a matter of style. As Derk said all "variables" and "objects" (In VBA I would have classified an array as a "variable" but in .NET it is now firmly an "object") should be destroyed as soon as they go out of scope. The trouble is there are some exceptions caused by bugs in the objects, complications in order of destruction ... So rather than risk bumping into one of these rare exceptions you can set all objects to Nothing.
If you do this for every variable/object it would be hard work. So, as I didn't see/hear/read of any issue with simple variables or sub objects (like Worksheet, Range ...), personally I'd leave those to garbage collector to sort out. I'm not sure if Ivan meant to incude these ?
BTW Great to see you at Ozgrid Ivan. We are honoured.
Participate now!
Don’t have an account yet? Register yourself now and be a part of our community!