I have a managed Windows application that loads a managed C++ component that uses AfxLoadLibrary to load a third party component if present on the client machine. Once detected, I’m unloading the component using AfxFreeLibrary in an attempt to lower the working set of the managed parent application.
The call to AfxFreeLibrary is successful (verified using Process Explorer), but no memory is freed up. Is this due to the nature of a managed application, or is there a way to free up this process space?
I’m not looking for alternative ways to tackle this problem in general, since the code is already in production, rather I would like to find out if the approach of unloading is worthwhile.
It should do, you can prove it by writing a pure native app and seeing the working set. However, working set is the size of the memory required to run the app, so if the code used by the dll can be swapped out, then the working set will not be reduced – Windows doesn’t count it as part of the working set.
If the dll has private memory allocated to the process, that cannot be swapped, then that does count and will reduce the working set.
so the answer is that it depends. Its not guaranteed to make any difference, and if the dll is not used, then it will have been swapped out and isn’t part of the current working set. You might as well not bother unloading it, unless you like to keep things tidy.
The only way to reduce the working set is to have your app use less memory. As its a .NET app, chances are you don’t have much control over it at all (as the GC will make its own mind up about how much memory is ‘active’ and needed in the working set)