ChooseCacheSize picks crazy numbers
|Reported by:||Philip Taylor||Owned by:||Jan Wassenberg|
|Priority:||Must Have||Milestone:||Alpha 5|
I'm on 64-bit Linux with 4GB RAM. In
ChooseCacheSize, I get values like
total == 3924,
available == 303. (I've apparently got around 1.2GB of OS caches/buffers, which are not counted as available - the available figure is always pretty low). That results in
ChooseCacheSize choosing its "below min-spec" path (which is silly) and returning 2304 MB (which is also silly, and if this were a 32-bit OS (with PAE) it could be trying to allocate more than the entire virtual address space which sounds problematic).
The calculation seems strange anyway, and lacking in rationale. We don't have 500MB of (public) game data (it's more like 250MB), the 'game' isn't 400MB (it depends on the amount of data and it often looks more like 200MB for me (including file cache)), we don't load all the data at once (the point of biomes was partly to cut the amount of data required per map by only using a well-defined subset). Also we have lots of other caches that reduce the need for everything to be kept in the file cache (I'm assuming it's only useful if a file gets loaded twice) and that contend with the file cache for RAM (it seems better to spend the RAM on higher-level caches to save on loading cost), so it's not clear that a large file cache has any benefit and/or doesn't cause any harm. Also it's contending with the OS disk cache, which will cache the compressed .zip file and therefore make better use of RAM than our own file caching.
Also it looks like
OperatingSystemFootprint is going to give a highly uninformative assertion failure message as soon as somebody runs the game on Windows 8 (and even when we update the code, people will still try running old releases), which sounds like a bad idea.
So it seems that this change is adding a lot of complexity and unpredictable non-deterministic system-dependent performance-affecting behaviour, without it being clear that it's any better than the old fixed-size cache. So I'd be much happier if either it was made much simpler again, or if it was made clear to me why I'm missing the point and it's actually a good idea :-)