High heap usage seems to have a huge adverse effect on our CPU usage.
Solutions
[x] completely phase out CollectiveManager.terrainBinaries if possible. Things that require them can probably calculate it on the fly, or use locally semi-cached data (like for base plans, cache until planning is completed
[ ] limit number of cached pathing matrixes floating in global. Ideally, there is only the defaultCostMatrix that the room provides. All costMatrixes should have a lastAccessed companion value, and they should be deleted if they haven't been accessed for awhile. Must first be converted over to roomData / communeData and handled by RoomDataOps/CommuneDataOps
[ ] similar timeout deletion for large data sets, such as IDs for structures and construction sites. Must first be converted over to the roomData and handled by RoomDataOps
[x] Patch the easy to patch holes in RoomManager and CommuneManager suspected data leakage.
[x] Ensure roomData and communeData don't have any kind of data leakage. Make sure that roomData room data objects are deleted at the rarest deletion interval
[ ] Investigate CreepClasses for adding leaky data to heap. It probably is. Add a task to fix it here if a fix outside of refactoring them seems doable.
Suspected heap leakage
data, such as cost matrixes and other properties of RoomManager and CommuneManager are likely being assigned when there is vision and then not deleted as intended next tick or some ticks thereafter. Therefore, data likely sits in those managers until the room is seen again and some of it is cleaned up (and more added, perhaps) or alternatively, heap resets.
This probably does an effective job of explaining the incremental increase in heap over an extended period until it is maxed out
If anyone else has ideas on what we can do to diminish our heap utilization while maintaining or improving CPU and memory efficiency, please let it be known
General Problem
High heap usage seems to have a huge adverse effect on our CPU usage.
Solutions
Suspected heap leakage
data, such as cost matrixes and other properties of RoomManager and CommuneManager are likely being assigned when there is vision and then not deleted as intended next tick or some ticks thereafter. Therefore, data likely sits in those managers until the room is seen again and some of it is cleaned up (and more added, perhaps) or alternatively, heap resets. This probably does an effective job of explaining the incremental increase in heap over an extended period until it is maxed out