You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Upon launching the Vault Hunters modpack (current release, 3.13.0), I noticed it had fairly high memory usage, so took a quick heap dump on the main menu to see if there was an optional mod I could disable or config I could tweak to reduce it somewhat with minimal gameplay impact.
Instead, I quickly noticed that there are a lot of PartialCompoundNBT instances from the_vault itself, yet nearly every single one of them was empty. I do not know if the game will mutate them later on or rely on identity inequality, justifying them being separate allocations despite being functionally identical, but if all of the empty ones can be modified to point to a singleton you should be able to drastically cut down on the pack's overall system requirements.
If you want to try reproducing my findings, take a heap dump at any point using your tool of choice, load it up into the Eclipse Memory Analyzer, and run a Component Report to see how many empty HashMaps it can find automatically. Or poke around manually in VisualVM, or any other tool that lets you explore Java heaps/dumps.
I haven't bothered to check whether there is much BlockPos duplication as well, so there might be a further hundred MB or two that can be optimized out.
The text was updated successfully, but these errors were encountered:
Upon launching the Vault Hunters modpack (current release, 3.13.0), I noticed it had fairly high memory usage, so took a quick heap dump on the main menu to see if there was an optional mod I could disable or config I could tweak to reduce it somewhat with minimal gameplay impact.
Instead, I quickly noticed that there are a lot of PartialCompoundNBT instances from the_vault itself, yet nearly every single one of them was empty. I do not know if the game will mutate them later on or rely on identity inequality, justifying them being separate allocations despite being functionally identical, but if all of the empty ones can be modified to point to a singleton you should be able to drastically cut down on the pack's overall system requirements.
If you want to try reproducing my findings, take a heap dump at any point using your tool of choice, load it up into the Eclipse Memory Analyzer, and run a Component Report to see how many empty HashMaps it can find automatically. Or poke around manually in VisualVM, or any other tool that lets you explore Java heaps/dumps.
I haven't bothered to check whether there is much BlockPos duplication as well, so there might be a further hundred MB or two that can be optimized out.
The text was updated successfully, but these errors were encountered: