There is often a problem with using wpf programs, that is, the memory usage is too high. The more complex the functions of programs using wpf, it often goes up to 90 while using the memory.
On the one hand, wpf itself is a UI framework. Although rendering images and interfaces improves the aesthetics of the software, it calls and consumes a lot of memory for collaborative processing during actual use;
On the other hand, the memory of these calls is indeed not released actively after use or only part of it is automatically released, that is, the managed resources are automatically cleaned and recycled through GC. For unmanaged resources, they are manually cleared through code calls and then recycled by GC. For example, streams, database connections, network connections, etc., so we need to actively and regularly recycle and release the memory.
LierdaCracker is highly recommended here
1. You can use nuget to manage the installation package, instantiate it in the Application_Startup method in the project and call the cracker method directly
LierdaCracker cracker = new LierdaCracker(); ();
2. Implement the LierdaCracker class by yourself
When it comes to C# resources and memory recycling, GC garbage collection mechanism is definitely indispensable. GC is solely responsible for the memory on the hosted heap. The memory referenced on the stack will automatically disappear with the demise of the stack space.
()； ();
This method forces instant garbage collection for all generations!
When the amount of memory used at a certain point in the application code is greatly reduced, it may be more appropriate to use it in this case. Instead, it provides waiting before collection is completed.
Another very important system API is also very important when releasing memory.
SetProcessWorkingSetSize, using this function to set the minimum and maximum running space of the application, will only retain the required memory. When the application is idle or the system memory is too low, the operating system will automatically call this mechanism to set the application's memory. Applications can also use VirtualLock to lock a certain range of memory and not be released by the system.
In fact, using this function does not improve any performance, nor does it really save memory.
Because it only temporarily moves the memory occupied by the application to the virtual memory, once the application is activated or there is an operation request, the memory will be re-occupied. If you force this method to set the memory occupied by the program, it may reduce system performance to a certain extent, because the system needs to frequently exchange pages between memory and hard disk.
BOOL SetProcessWorkingSetSize( HANDLE hProcess, SIZE_T dwMinimumWorkingSetSize, SIZE_T dwMaximumWorkingSetSize );
Setting the 2 SIZE_T parameters to -1 can make the memory used by the process switch to virtual memory, retaining only a small part of the code. It is a Windows NT API, so the usage needs to be added to the platform conditions.
if ( == PlatformID.Win32NT) SetProcessWorkingSetSize(().Handle, -1, -1);
In summary, LierdaCracker class is
public class LierdaCracker
{
[DllImport("")]
private static extern bool SetProcessWorkingSetSize(IntPtr proc, int min, int max);
private void FlushMemory()
{
();
();
if ( == PlatformID.Win32NT)
SetProcessWorkingSetSize(().Handle, -1, -1);
}
public void Cracker(int sleepSpan = 50)
{
_ = (delegate
{
while (true)
{
try
{
SetDate();
FlushMemory();
(((double)sleepSpan));
}
catch { }
}
});
}
}This is the article about the implementation of WPF memory recycling and release of LierdaCracker in C#. For more related content, please search for my previous articles or continue browsing the related articles below. I hope everyone will support me in the future!