CPU Spikes when buildables are processed #3
Description
This is going to be documented here, as DiFFoZ reported it as happening, and it is a known issue but not obvious at first due to the deferred and multi-threaded nature of buildable processing.
To be clear: the problem lies within the clustering part of the plugin, as its extremely inefficient at this moment for one-to-one changes, but works much better in bulk.
However, it still takes quite some time to finish processing, and of course, spikes the CPU up due to its inefficiency.
Currently, the following actions must be caught for clustering to work as intended:
- A buildable is removed
- A buildable is added
- A buildable changes its position (Note, this is basically the same as removing a buildable and adding it elsewhere. This is how it is handled internally)
From that, the clusters should do one of the following actions:
- Shrink the cluster (remove the affected buildables)
- Split the cluster (a buildable connected 2 other buildables within the same cluster, which are no longer connected under any circumstance)
- Expand the cluster (add any connected buildables)
- Merge the cluster (a buildable now connects 2 separate clusters together)
Additionally, any of the following actions should happen where necessary:
- A cluster with no more buildables, or unneeded is returned to the object pool for use in the future
- A cluster that expands must steal barricades from the global cluster which are now in range
- A cluster that shrinks must return barricades to the global cluster which are no longer in range
The code that handles all of this is split in a couple locations:
Cluster shrinking, splitting and returning: https://github.com/Pustalorc/BaseClustering/blob/master/API/BaseClusters/BaseCluster.cs#L281
Cluster expansion, merging and stealing: https://github.com/Pustalorc/BaseClustering/blob/master/API/BaseClusters/BaseClusterDirectory.cs#L525
If anyone has any ideas for optimizing or improving this entire workload, feel free to open a PR or comment here.