ENBboost memory management
These tests demonstrate the improved memory efficiency of Skyrim when running ENBBoost, by Boris Vorontsov.
ENBboost uses a customised DLL file to impose new behaviour on the Skyrim engine, and the way it handles memory and VRAM. It forces the engine to make greater use of available VRAM, with less mirroring of video data in Windows memory. This is significant, since Skyrim is a 32bit application with a 4GB limit on its memory usage, and has to date created a ceiling on the modded textures we could add to Skyrim. This limitation has widely been described as the "3.1GB Limit", though this figure is actually somewhat arbitrary, derived from anecdotal reports. As we will see, the standard metric used to measure an application's memory usage is known as the "Working Set", and this is an inaccurate measurement that is always lower than the true memory usage. The so-called 3.1GB crash is almost certainly the result of Skyrim approaching its expected 4GB limit of Windows memory, and this is the fundamental problem that ENBboost addresses.
This is a sophisticated approach that can be shown to significantly improve memory usage. However, it remains unknown what new problems might be introduced by this approach, and how it could affect stability.
The ENBboost results are compared to those of some other utilities, which use simple techniques to create misleading memory-usage figures, in order to claim that they too improve memory efficiency. These comparisons serve to illustrate both the failings of these apps, and the efficacy of ENBboost. The figure that is displayed to represent the memory usage of Skyrim (in the Windows Task Manager, Skyrim Performance Monitor, etc.) is known as the "Working Set". The business of Windows memory management becomes quite complex, but the key point to understand about the Working Set of memory assigned to Skyrim, is that it is not a whole and accurate representation of all the memory it is using - it is a particular subset of Skyrim's total memory usage.
Determining the total, accurate memory usage of an application is actually very difficult, and, in normal usage, this inaccurate Working Set figure can be useful to give a rough picture of the memory usage of an application. This is why it is often relied upon by memory monitoring software, to provide a reasonable estimation.
Many bogus applications that claim to reduce memory usage operate by a simple system command that forces Windows to "account" for memory usage differently - it forces the memory that was classified as part of the Working Set to be counted in a different area, making it appear to the memory-monitoring apps that memory use has been reduced. However, in reality, the memory use is not reduced at all by this procedure. It is simply shifted into a "different column" in the accounting system, hiding it from the monitor apps. It is rather like an accountant hiding money in the Cayman Islands - the true wealth of the tax-dodger remains the same!
We will use a tool known as VMMap to have a closer look at what is going on with Skyrim's memory usage when using this bogus method, and compare this to the results in the same game conditions when using ENBboost.
These tests use a Skyrim setup with a heavy load of unoptimized texture mods. SKyrim is simply loaded up in three different locations:
- In Riverwood
- Outside Riften
- Outside Solitude
In each of these locations, VMMap and the WIndows Task Manager are used to measure memory use in three different conditions:
- Memory Usage default- without ENBboost or a bogus app
- Memory Usage immediately after "cleaning" with a bogus app
- Memory Usage with ENBboost
Skyrim is closed and reloaded to each save location after each test.
Riverwood Memory Usage - Default
There is a lot of information here, but we can focus just on the three main bars at the top of the UI: Committed, Private Bytes, and Working Set. Simply, these can be thought of as three different ways of counting different aspects of the memory use of Skyrim (TESV.exe).
It can be seen that the Working Set figure for TESV.exe is almost the same in both VMMap and Task Manager, and the difference is explained by differing times at which they measure this slightly fluctuating amount. In VMMap, look at the figure for Private Bytes: 1,456,756K. Then look at the Working Set, which measured differently - it is a similar figure, at 1,418,428K. Bear these figures in mind as we look at TESV.exe again, after running a bogus "memory cleaner" app.
Riverwood Memory Usage - after cleaning
See how the figure for the Working Set has been reduced to almost nothing, 9776K as measured in VMMap, and a similar figure in the Task Manager. But also observe how the figure for Private Bytes has not changed. This is because the true memory usage of TESV.exe has not changed. A simple command has been invoked, which has temporarily changed the in which memory is accounted for, making the Working Set figure hugely misleading.
Riverwood Memory Usage - using ENBboost
After loading the same location with ENBboost enabled, we can see that the different measures of memory use for TESV.exe are again much closer to agreement. We can also see that the Private Bytes figure now reports 590,844K - a reduction of almost 1GB from the default memory usage, and the other measurements reflect this. It seems clear that ENBboost suceeds in greatly reducing actual memory use for the SKyrim process, as opposed to the misleading reading of the bogus app.
Here are the same measurements, taken at the other two test locations.
Outside Riften Results
Outside Riften Memory Usage - default
Outside Riften Memory Usage - after cleaning
Outside Riften Memory Usage - with ENBboost
Outside Solitude Results
Outside Solitude Memory Usage - default
Outside Solitude Memory Usage - after cleaning
Outside Solitude Memory Usage - with ENBboost
|Default Private Bytes||Default Working Set||"Cleaned" Private Bytes||"Cleaned" Working Set||ENBboost Private Bytes||ENBboost Working Set||ENBboost reduction of Default Private Bytes|
In normal usage, it can be seen that the Working Set figure reported by the monitoring apps is lower but roughly in line with the other measurements, and is a reasonably useful guide to memory usage. Only when deliberately distorted does it become useless and misleading. It can also be seen that ENBboost results in a large actual reduction in memory usage, confirmed by all measurements reported by VVMap.
Wider testing is required to support these results. However, based on these findings, we should begin serious testing of ENBboost, particularly with regard to stability, and torture testing to find the new higher limits. This may well be an important part of STEP, going forward.