How to Reduce the memory usage of Windows programs

* Note: During the optimization of the system over the past few days, it was found that the entire software took up MB of physical memory as soon as it was started, and it was a little hard on the HP Workstation, let alone on a normal PC. However, I found that the physical memory usage was only about 10 MB after the software was minimized, so I felt that there was still room for optimization for the entire software. I searched the internet and found some solutions. However, I felt that the following article was more professional, so I reprinted it for emergency purposes.

During program performance optimization in the project, it was found that the setprocessworkingsetsize () method was used to reduce the memory a lot, so I checked the relevant information as follows.

1. Working Principle of setprocessworkingsetsize

From:

So why can my program move the occupied memory to the virtual memory?

In fact, you can also try to minimize a program to the taskbar, and then look at the task manager. No, the actual memory occupied by your program is suddenly reduced, it seems that I don't have any way to compress the memory, but the operating system itself has this mechanism, that is, when the program is not in use (minimized), the operating system will call some commands, to move the memory occupied by the program to the virtual memory, only a small part of the common code is retained.

So we can see that the memory usage is reduced at once.

So: what commands did the system call? Can I release the memory without narrowing down the form?

Look at this API setprocessworkingsetsize

This is the original answer from msdn.

Using the setprocessworkingsetsize function to set an application's minimum and maximum working set sizes does not guarantee that the requested memory will be reserved, or
That it will remain resident at all times. when the application is idle, or a low-memory situation causes a demand for memory, the operating system can reduce the application's working set. an application can use the virtuallock function to lock ranges
The application's virtual address space in memory; however, that can potentially degrade the performance of the system.

Use this function to set the minimum and maximum runtime space of the application, and only reserve 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 memory. Applications can also use virtuallock to lock a certain range of memory from being released by the system.

When you increase the working set size of an application, you are taking away physical memory from the rest of the system. This can degrade the performance of other applications
And the system as a whole. it can also lead to failures of operations that require physical memory to be present; for example, creating processes, threads, and kernel pool. thus, you must use the setprocessworkingsetsize function carefully. you must always
Consider the performance of the whole system when you are designing an application.

When you increase the runtime space for applications, the physical memory you can obtain depends on the system, which may cause other applications to degrade performance or the overall system performance, this may also cause the request to the physical memory operation to fail. For example, to create a process, thread, or kernel pool, you must use this function with caution.

======================================

In fact, using this function does not improve performance or actually save memory.

Because it only temporarily moves the memory occupied by the application to the virtual memory. Once the application is activated or has an operation request, the memory will be occupied again. If you use this method to set the memory occupied by the program, the system performance may be reduced to some extent because the system needs to frequently perform page exchanges between the memory and the hard disk.

Bool setprocessworkingsetsize (

Handle hprocess,

Size_t dwminimumworkingsetsize,

Size_t dwmaximumworkingsetsize

);

Set the two size_t parameters to-1, that is, the memory used by the process can be switched to the virtual memory, only a small part of the code is retained.

The reason why the table calendar show can always keep the Minimum Memory is that the timer is used and the operation is not stopped. Therefore, the performance can be imagined. Although it is in exchange for the illusion of small memory, it is indeed a disaster for the system.

Of course, this function is not all right,

1. When our application is just loaded, you can use this operation once to put the code not required in the loading process into the virtual memory. In this way, after the program is loaded, maintain a large amount of available memory. VB

2. When the program runs for a certain period of time or the program is about to be idle, you can use this command to swap the occupied memory to the virtual memory.

Finally, attach the API code called by VB

Option explicit

Private declare function setprocessworkingsetsize lib "Kernel32" (byval hprocess as long, byval dwminimumworkingsetsize as long, byval dwmaximumworkingsetsize as long) as long

Private declare function getcurrentprocess lib "Kernel32" () as long

Setprocessworkingsetsize getcurrentprocess,-1,-1

Place the memory used by the current process to 0.

2. Distinguish physical memory, virtual memory, Working Set (memory), and memory

From:

This problem has been encountered several times in csdn. I only give a simple answer each time: do not refer to the mem usage data of task manager. The data size has no direct impact on program performance.

The following are some of my ideas on this issue. I hope to help anyone who is interested in this issue.

Q: Is. Net alone?
A: Nope! As saucer said earlier, this is not a. Net problem. All Windows programs have similar behaviors. For example, the following C program:
Void main {While (1) ;}// an endless loop, which allows us to view the Task Manager

The mem usage on my machine for the first time is 632 KB. After the console is minimized, the memory usage becomes 36 KB. Obviously, this is not a. net issue, but a Windows memory management issue. So there is not much to do with the. net gc mechanism-although the problem is easily reminiscent of GC.

Q: How much memory does my program use?

A: It is not easy to answer this question. Let's take a look at some basic concepts of Virtual Memory Management in the operating system: Every Windows Process has 4 GB of address space, but your machine obviously does not have 4 GB of physical memory. In a multitasking environment, the total memory used by all processes can exceed the computer's physical memory. Under certain circumstances, a part of the process may be deleted from the physical memory and saved to the hard disk file (pagefile ), when a process tries to access the memory exchanged to pagefile, the system will generate a page fault ), at this time, the Windows Memory Manager is responsible for re-transferring the corresponding memory page from the hard disk to the physical memory.

In a certain period of time, the physical memory that a process can directly access (without page interruption) is called the working set of this process; the memory that a process actually allocates (COMMIT) from a 4G address space is called committed virtual memory. Committed VM may exist on page
In file, the workingset must be in the physical memory.

To answer the above question, you must first ask: What're you talking about? Physical memory or committed memory?

Q: What is this "mem usage" data?
A: From Task Manager Help: In task manager, the current working set of a process, in kilobytes.

The mem usage name is somewhat misleading. It only indicates the physical memory occupied by the process, that is, workingset. Workingset does not indicate that the process currently occupies all the virtual memory, and some data may be exchanged to pagefile. The data is loaded to the physical memory only when accessed.

Task Manager has another column of data: VM Size, indicating the virtual memory allocated by a process (committed visual memory). The actual definition is more complex than this one, however, this definition is sufficient for our current analysis. The previous C program is used as an example. The VM Size before and after the minimum is 176 KB, but it does not change.

Therefore, the conclusion is very simple: when a Windows program is minimized, the Windows Memory Manager minimizes the workingset of the process (based on first-in-first-out FIFO or least-recently LRU ), swap most of the data into pagefile. This is easy to understand: We usually want to leave more physical memory for foreground applications to achieve better performance. When the program is restored from a minimum, Windows does not fully load all the virtual memory of the program, but only loads the necessary part. This is also easy to understand: the code in the program startup phase is usually seldom accessed after startup (.. net programs, especially for modules such as fusion, which are usually not used if reflection is not used after the program is loaded normally ).

Q: So, do we want a smaller workingset, or a larger one?
A: It depends. Conventional wisdom tells us: the smaller, the better. If workingset is too small, many page-missing interruptions will occur during the program running, which seriously affects the program performance. On the other hand, workingset is a waste of "valuable" physical memory, reducing the performance of the entire system. Generally (unless it is an application that is very performance-sensitive and you have full knowledge of Windows Memory Management), we recommend that you do not adjust the size of workingset in the program.
This task is handed over to the Windows Memory Manager. The adjustment method saucer mentioned :();

Q: final question, does my program really occupy that much physical memory?
A: The question seems to be a bit confusing-The number is clearly written in the task manager.
The results of the vadump check show that the workingset of the process is reduced mainly because many DLL files are not loaded to the physical memory when they are restored from the minimum. We know that one feature of DLL is code sharing, with NTDLL. DLL is used as an example. Almost all applications in the Windows System (specifically, all programs in the Win32 subsystem) need to reference NTDLL. DLL. If each file is a copy, the file occupies dozens of megabytes of memory. In Windows, the solution is to save only one copy of NTDLL. dll in the physical memory.
All programs that reference this DLL map this copy to their own memory space and share the ntdll. DLL code segment (the data segment of each process is still independent ). So although NTDLL. the DLL size is calculated in the workingset of your program, but removing the reference to this DLL from your program won't actually release much physical memory-you don't need, others are still using it!

Therefore, the physical memory occupied by your program is much less than the memory occupied by MEM usage. You need to deduct many shared code pages from mem usage (which can be seen in vadump ).

Conclusion? Do not refer to the mem usage data of task manager. The data size has no direct impact on program performance. Using the. NET counter in the perfomence monitor is much easier and more accurate.