Blockstate caching
Pannoniae opened this issue ยท 2 comments
Forgive me if this is a stupid question, please.
The game generates every blockstate on startup instead of generating them upon usage. Most modpacks have about 300000 blockstates, or somewhere in the six digits. Since every blockstate uses at least 120 bytes (I've added the fields in the AbstractBlockState class together but I think it's more in practice since there is overhead for the pointer + other stuff I've missed)
I wonder if it would be possible to only generate blockstates upon access to reduce memory usage. The vanilla game iterates over them in a few places (like VineBlock) so that would be a problem and I am not sure if that can be patched.
Again, sorry if I am speaking complete gibberish, I am not a modding expert or anything.
That might be theoretically possible, but
a) it would be highly problematic for mod compatibility (I'm trying to keep all "modder-observable" behavior)
b) it would not actually do much compared to the risk and work. The blockstates themselves account for somewhere around 40 MB of heap usage.
What would be interesting target is AbstractBlockState.Cache
. That class accounts for most of the memory used by blockstates. As I said above the states themselves are 40 MB total. The caches are around 135 MB, and it might be feasible to at least delay creating them. I've ignored that area so far since @LatvianModder has been looking into it and I didn't want to end up with two incompatible mods.
By the way, there are much better ways of looking at the memory usage of things than manually adding field sizes and guessing numbers. Launch some modpack, take a heapdump (VisualVM can do it, I use jcmd
) and open it in some heap dump analyser. I use Eclipse Memory Analyzer, which has the advantage that it writes most of its caches to disk, so I can re-open a dump quickly.
(Numbers are for the DW20 pack)