Excessive memory allocation in MyLargeTurretTargetingSystem

The turret controller's target visibility cache logic is slow, primarily due to allocating too much memory. You don't need to do anything in the world, it is enough to have a lot of AI controlled turrets with other grids in their range (they don't have to be enemy ones).

For dotTrace settings see the attached screenshot on the visibility cache update method. Follow the yellow highlighting.

As I already described in the ticket's description (please read the whole text), the cache is based on ConcurrentDictionary, which has horrible performance. Also, when the code calls Clear on such a dictionary it just re-allocates its hash table. So clearing does not actually reuse the data structure, your optimization attempt was futile. Always verify the library implementation instead of making assumptions about its time/memory complexity. Otherwise you can run into surprises, like this one.

Know what is the goal of your target visibility cache.

Each target for each turret controller can be in one of the following 3 states:

• Not cached (visibility is unknown)
• Cached as visible
• Cached as not visible

Define clear expiration times in simulation ticks for each of the cached states. Do not use a frequent full scan of the dict to remove expired item, just sore an expiration timestamp (future tick count) within the item and ignore expired items on lookup. Then you can do the cleanup rarely and at a limited rate.

Please see how I implemented it using the above strategy with a single dictionary and R/W locking, which is much faster and seems to work well in practice: https://github.com/viktor-ferenczi/performance-improvements/tree/main/Shared/Patches/TargetingSystem

The IL files are there only for comparison, to see how the transpiler patches change the code to call my implementation. The relevant part is in the cs file and outside in the Share.Tools namespace where the UintCache object is defined. I use a custom RwLock, but it could be some other locking you're using.

Also, try to avoid memory allocations at performance critical parts which are called very frequently. They are evil, because they not only consume CPU power, but summons a GC collection run later causing lag, even if running in parallel.

You can find SortTargetRoots as well in a similar way, please see under Remarks in the ticket description on what's the problem there with array resizing.

Please leave a comment if something is not clear.