Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Actions to significantly reduce heap usage #774

Closed
3 of 6 tasks
CarsonBurke opened this issue Jan 30, 2024 · 1 comment
Closed
3 of 6 tasks

Actions to significantly reduce heap usage #774

CarsonBurke opened this issue Jan 30, 2024 · 1 comment
Assignees
Labels
Help wanted ideas, code or feeedback is requested from other contributors Improvement Presumably positive changes to existing functionality

Comments

@CarsonBurke
Copy link
Member

CarsonBurke commented Jan 30, 2024

General Problem

High heap usage seems to have a huge adverse effect on our CPU usage.

image

Solutions

  • 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
  • Patch the easy to patch holes in RoomManager and CommuneManager suspected data leakage.
  • 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

@CarsonBurke CarsonBurke added the Improvement Presumably positive changes to existing functionality label Jan 30, 2024
@CarsonBurke CarsonBurke self-assigned this Jan 30, 2024
@CarsonBurke CarsonBurke added the Help wanted ideas, code or feeedback is requested from other contributors label Jan 30, 2024
@CarsonBurke
Copy link
Member Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Help wanted ideas, code or feeedback is requested from other contributors Improvement Presumably positive changes to existing functionality
Projects
None yet
Development

No branches or pull requests

1 participant