I noticed that AAU2 is not releasing RAM correctly, leading to frequent microfreezes and also several seconds freezes. This happens for several reasons:
Initial RAM used after game has terminated loading is not released once at the main menu
RAM is not released properly after terminating any flight and returning to main menu
RAM is not released periodically during a regular flight
I run game on Windows 11, DX12, 3840x1600 with 125% scaling and all settings maxed using TLOD 200 and OLOD 200. System is 12900ks + 4090 + 64 GB RAM at 5200 MHz. I get similar results when using DX11 mode.
After game has loaded completely and I´m at main menu RAM used by game is around 10 GB. That value can stay in the 8-16 GB afterwards depending on the area, after several flights have been completed.
I run a test flight using Bell 407 from LKMK to LKTB following 4 POIs (castles) to the north of Brno city, in the Czech Republic, which is a quite generic World Update countryside area not so heavy in terms of graphics but still with several villages, nice details and a variety of terrain elevations. I got freezes periodically and even longer ones lasting 5 seconds each every few minutes, and the RAM usage was increasing above 10 GB and staying always above that figure.
I repeated test, but once at the cockpit I have forced a memory clearing using Process Lasso´s memory trim feature, which instantly reduced RAM usage in MSFS to less than 1 GB. Then game started to use more RAM as I followed my flight plan and stayed around 3 GB only for almost 30 minutes (7 GB less). I had no freezes at all and flight was completely smooth.
The following pictures show HW usage during a period of 15 min only but results are consistent for the other 15 min the complete test lasted. You can observe how the RAM usage has barely changed (min and max values). CPU graph was also showing a very steady figure with FPS in the range of the 50s. VRAM was staying on the 10 GB range as well.
AAU2 has a serious memory management issue, not only leading to CTDs but also to significant performance degradation due to not optimized memory usage. Please MS/Asobo take a look on that as game can run really fine by simply releasing memory properly. If not done all garbage from the last minutes and even previous flights, which is not required at all, stays there affecting overall system performance.
Just clearing memory after game has terminated loading is enough alone to improve overall performance but if it´s also cleared periodically (every few minutes and after returning to main menu) then performance figures are improved a lot. As you can see game just needs around 3 GB to cache a generic area at ultra settings for a half an hour VFR flight but it´s currently using around 10 GB. There´s no reason for such a high RAM usage.
Thanks for that diligent research and report. It’s a feeling I’ve had without anything like this scientifically detailed info to back it up!
I hope this gets higher up the chain for them to verify and ensure the next update is better in this regard!
A question though: why doesn’t having 32gb or 64gb ram (like we both have) not make this usage irrelevant. There is always spare “room” for the game, no?
There’s room to use, sure but it has sense when you store nearby scenary data, specially the incomming one or if the rendered area is complex or big. This helps when panning camera. But there’s no point to keep in memory data from the last 50 miles you already passed for instance. While in memory the already passed scenery just makes the data size our system needs to move/handle bigger.
I don’t know what information you used to make these points because Windows allocates and releases RAM as needed, not MSFS. MSFS allocates internally its virtual memory between code and data and then Windows allocates and maps RAM to MSFS virtual memory. When MSFS is done with any of its virtual memory, it notifies Windows and Windows manages the newly freed RAM. MSFS manages only its virtual memory. It cannot and should not manage RAM. (RAM is the physical amount of memory in a PC. Virtual memory is memory needed by a program independent of RAM.)
The RAM used by MSFS is returned to Windows at MSFS exit.
RAM is released when no longer needed by Windows after flight termination. I’m not sure what “properly” means.
RAM is released when no longer needed by Windows during flight. I’m not sure what “periodically” means.
Here is a graph showing Windows RAM allocation and release for MSFS:
At MSFS start, lots of RAM is allocated as expected. Additional RAM is allocated when a flight starts.
During flight RAM allocation dynamically changes showing additional RAM allocation during landing.
RAM allocated during flight is released when returning to the Main Menu.
This RAM allocation does not change while using the Main Menu. I’m not sure WHY it would be released during this time.
When MSFS exits, all of the RAM it is using is returned to Windows.
We really don’t know how MSFS allocates its virtual memory for code and data so there isn’t any way to determine if there is a serious virtual memory management issue. There MAY BE an issue with how Windows manages RAM memory causing performance degradation but that is a Windows problem. The debate about Windows optimizing its memory management has been ongoing for decades.
How does not releasing its own virtual memory affect overall system performance? What is wrong with the “garbage” from previous minutes or flights? If MSFS doesn’t need that RAM any more, Windows will take care of it. Granted there is overhead due to Windows memory management but that is an integral part of Windows. (Also there is the overhead of Project Lasso and other system performance and tuning programs that run at a higher priority than MSFS.)
This isn’t like the good old days when Flight Simulator was ONLY DOS-based. Memory management was KEY to overall performance because Flight Simulator performed RAM management as part of its virtual memory management (along with video memory management and device management). Efficient garbage collection was vital to good performance. Today, Windows manages all of the real memory including “garbage collection”.
The reason for high RAM usage is that MSFS is a huge program with a huge amount of code and a huge amount of data.
That issue led to performance degradation and FPS falling to the 20s while the process was active having a significant hit on big urban areas and in general while on ground at any medium to big size airport with main thread being hammered and reproducing lots of peaks. Final SU10 version addressed the required memory optimizations and title has been relatively stable up to SU12 more or less. After the release of the avionics updates we basically came back to the status we had prior to SU10.
Now overall performance at ground has been reduced by almost 10fps compared to SU12. The performance is droping again to the 20s values during several seconds until all data is stored or released and we are facing again hitching and even several seconds freezes, which were not reproduced under SU12 for instance. You can see how main thread is again hammered and reproducing the same peaks every few ms that we had last summer. With SU12 the developer mode graph was showing a steady graph with just sporadic peaks every few minutes as soon as new scenery was cached.
