How to release IDispatch memory.
-
In my application, i am using a ocx. I created an object to one of the interface in the ocx and called a function on that interface from my application. The return type is LPDispatch data. once i call that function, the memory of my exe is increasing since some memory is creating in that function may be. Now my question is how to release that memory once my work is done with LPDispatch data. i called release() but it dint help me. Can some one help me in deleting the memory in my application created by that function in ocx.?
-
In my application, i am using a ocx. I created an object to one of the interface in the ocx and called a function on that interface from my application. The return type is LPDispatch data. once i call that function, the memory of my exe is increasing since some memory is creating in that function may be. Now my question is how to release that memory once my work is done with LPDispatch data. i called release() but it dint help me. Can some one help me in deleting the memory in my application created by that function in ocx.?
You should show us the basic code (how you get the interface pointers). In general, you have to call
Release()for each kind of interface object when not used anymore. This applies to all pointers retrieved by calling for exampleCoCreateInstanceandQueryInterface. If a called function is allocating memory internally and returning that to the caller it should be documented. The documentation should then include how to free the memory (e.g. withCoTaskMemFree). -
In my application, i am using a ocx. I created an object to one of the interface in the ocx and called a function on that interface from my application. The return type is LPDispatch data. once i call that function, the memory of my exe is increasing since some memory is creating in that function may be. Now my question is how to release that memory once my work is done with LPDispatch data. i called release() but it dint help me. Can some one help me in deleting the memory in my application created by that function in ocx.?
Member 10253026 wrote:
Can some one help me in deleting the memory in my application created by that function in ocx.?
If your windows application allocates 1GB of RAM... then properly releases it... Yes; the operating system is very lazy in returning that memory back to the system. This is by design. You should not do anything and allow the OS to manage memory. The OS is very good at this. In theory you should be able to do:
SetProcessWorkingSetSize(-1,-1);
or
EmptyWorkingSet(YourPID);
This will force the OS to release all unused pages assigned to your application. But trust me... this is not necessary and will most likely do more harm than good. Best Wishes, -David Delaune
-
You should show us the basic code (how you get the interface pointers). In general, you have to call
Release()for each kind of interface object when not used anymore. This applies to all pointers retrieved by calling for exampleCoCreateInstanceandQueryInterface. If a called function is allocating memory internally and returning that to the caller it should be documented. The documentation should then include how to free the memory (e.g. withCoTaskMemFree).Thanks. Please find the code
VARIANT Attributessets;
VariantInit(&Attributessets);m_OcxObj->GetAttributes(ID, &Attributessets);
// here we got the data in variant as LPDispatch....here memory increases
//even if we do Attributessets.pdispval->Release(), memory is not released
Attributessets.pdispVal->Release() //it dint release memory.
-
Thanks. Please find the code
VARIANT Attributessets;
VariantInit(&Attributessets);m_OcxObj->GetAttributes(ID, &Attributessets);
// here we got the data in variant as LPDispatch....here memory increases
//even if we do Attributessets.pdispval->Release(), memory is not released
Attributessets.pdispVal->Release() //it dint release memory.
How did you know that the memory is not released and how do you determine the memory used by your application? You have to know how the memory is managed which requires knowing the used allocation method. Most memory is allocated in the default per-process heap. If this heap is used up, it is resized by requesting more memory from the operating system. But it will not shrink (at least not immediately) when freeing memory (which occurs when the reference count reaches zero upon releasing). It is finally returned to the operating system when the process terminates. As a result, you might see increasing process memory usage while the process is running. There is a rather old article that explains the heap managment for Windows: Heap: Pleasures and Pains[^]. In your case of a
VARIANTset by a OCX function you have no control over the memory management and even did not know which allocation method is used. If an object must be released depends on the data stored in theVARIANTand should be part of the documentation. In your case of apdispVal, the OCX control might for example increase the reference count for the dispatch when callingGetAttributes(). Then it will be released finally when releasing the OCX control or you have to callRelease()which should be again mentioned in the documentation. It depends also on what you are doing with the interface. If you are calling dispatch functions that increase the reference count, you have to callRelease()the same times. -
How did you know that the memory is not released and how do you determine the memory used by your application? You have to know how the memory is managed which requires knowing the used allocation method. Most memory is allocated in the default per-process heap. If this heap is used up, it is resized by requesting more memory from the operating system. But it will not shrink (at least not immediately) when freeing memory (which occurs when the reference count reaches zero upon releasing). It is finally returned to the operating system when the process terminates. As a result, you might see increasing process memory usage while the process is running. There is a rather old article that explains the heap managment for Windows: Heap: Pleasures and Pains[^]. In your case of a
VARIANTset by a OCX function you have no control over the memory management and even did not know which allocation method is used. If an object must be released depends on the data stored in theVARIANTand should be part of the documentation. In your case of apdispVal, the OCX control might for example increase the reference count for the dispatch when callingGetAttributes(). Then it will be released finally when releasing the OCX control or you have to callRelease()which should be again mentioned in the documentation. It depends also on what you are doing with the interface. If you are calling dispatch functions that increase the reference count, you have to callRelease()the same times.Thanks for the information provided. For the question: How did you know that the memory is not released and how do you determine the memory used by your application? we call this Getattributes() method in a for loop. for every iteration, it takes around 8 KB memory and finally at the end of this loop process memory shoots up by 50 MB,which is unwanted for us. we did call Release()method on the pDispval once. but did not work.. i will once again explain the worflow and my questions to give more clarification.. First we get the attributes from the OCX interface using GetAttributes() and we get variant with Pdispvalue.... Does OCX increase the refernce count of Pdispvalue to one here ? Then we attach this pdispval to the OledispatchdriverObject using AttachDispatch()...Does the refrence count go to two ? OCX gets destroyed only when main application ends but increase in the memory effects our application. Do i need to call Release() twice on the pDispval to make it clear ? Does memory gets freed at the end of second Release() call or is it the OCX destruction that clears it.
-
Thanks for the information provided. For the question: How did you know that the memory is not released and how do you determine the memory used by your application? we call this Getattributes() method in a for loop. for every iteration, it takes around 8 KB memory and finally at the end of this loop process memory shoots up by 50 MB,which is unwanted for us. we did call Release()method on the pDispval once. but did not work.. i will once again explain the worflow and my questions to give more clarification.. First we get the attributes from the OCX interface using GetAttributes() and we get variant with Pdispvalue.... Does OCX increase the refernce count of Pdispvalue to one here ? Then we attach this pdispval to the OledispatchdriverObject using AttachDispatch()...Does the refrence count go to two ? OCX gets destroyed only when main application ends but increase in the memory effects our application. Do i need to call Release() twice on the pDispval to make it clear ? Does memory gets freed at the end of second Release() call or is it the OCX destruction that clears it.
Member 10253026 wrote:
First we get the attributes from the OCX interface using GetAttributes() and we get variant with Pdispvalue.... Does OCX increase the refernce count of Pdispvalue to one here ?
This should be part of the OCX documentation. I guess that the reference count is incremented.
Quote:
Then we attach this pdispval to the OledispatchdriverObject using AttachDispatch()...Does the reference count go to two ?
AttachDispatch()will increment the reference count. So you have to callRelease()or setbAutoRelease. But when usingAttachDispatch()yourOleDispatchDriverobject will be the owner of the interface. So you should not use thepDispValmember of theVARIANTafterwards anymore (set it toNULLto avoid using it). Memory is only freed when the reference count becomes zero when callingRelease(). I suggest to check the return value when callingRelease(). Then you will know when memory is freed. To check the actual reference count without releasing, just callAddRef()andRelease().