I don’t see any linear relationship between map file size and memory consumption.
GG uses large address array allowing access to more than 2gb of ram even though a 32bit app.
Video ram is dependant on graphics card - often 2 gb.
The map bank file contains indexes to entities for the map and a terrain data file alongside a few other texture and data files sometimes needed but not always.
Load time is determined mostly by the number of entities on the map and the textures associated with those entities. Initial loads will take longer as AI obstacles are calculated but these are saved for future use.
Breaking the video ram cap of the graphics card will cause stuttering as the card moves textures in and out of memory. Textures that are used often (called a lot via draw calls) will be cached so keeping a critical eye on texture size is vital to maintaining smooth running. Make sure that entities that use the same texture are all sourced in the same entity folder as these won’t be loaded twice they will be reused once loaded.
Entities and associated structures and data including scripts need system ram. This can run upto 3gb without issue (assuming the pc has at least 8gb ram). Usually it is texture memory that is exhausted first.
Once/if FPS drops below 20-25 then animation and scripts will start to exhibit issues. If this happens reduce overheads that impact FPS (not caused by memory usage) such as post processing (depth or motion blur or disable completely by moving bloom slider to zero), shadows, light rays.
Once FPS recovers, animation and scripts will too.
If most of the textures (for entities) are used in all levels then don’t set standalonefreememory.. to 1. Only use this if levels use mostly different textures.
There is a very slow memory leak that does consume a few kb of ram sporadically but often during game play. I haven’t found the cause of this yet.
Just relaying my testing results