Opened 3 years ago
Last modified 2 years ago
#5962 new enhancement
UnitAI Gathering optimisations
Reported by: | wraitii | Owned by: | |
---|---|---|---|
Priority: | Should Have | Milestone: | Backlog |
Component: | Simulation | Keywords: | performance, simple |
Cc: | Patch: |
Description
UnitAI's "GATHER.GATHERING" is called often (1/rate, which is around once per second) for each gathering entity. Because it does a fair few computations in its Timer Handler (checking if we still can gather, checking the range, gathering, possibly doing some dropsite related checks), it ends up being a large part of the sim Update in the late game (easily taking upwards of 10ms/frame).
There are two main things we could do:
- Avoid sending 2 messages in Perform Gather (resource Carrying & resource Supply changes). Only AIProxy subscribes, and the messages are usually redundant because multiple entities generally gather from one Supply. From profiling I'd guess this cuts time by ~10-20%.
- Here the solution would be to dynamically subscribe resourceSupply/Gatherer AIProxy (_maybe_ just supply) so that on turn's end, it queries its state and sends it to the AI. Avoids redundant work. When playing with no AI, could be de-activated entirely.
- Increase the timer interval. We currently collect one resource each "timer", but we could run the timer 2x less often and just collect 2 resources. I think given the capacities our entities have, this would be a good optimisation, effectively reducing work by 2x, and thus possibly saving up to 50% computation time.
Change History (8)
comment:1 by , 3 years ago
comment:3 by , 3 years ago
Component: | UI & Simulation → Simulation |
---|
comment:4 by , 3 years ago
Milestone: | Alpha 25 → Alpha 26 |
---|
I think the 500->200ms turn change has indirectly helped with this. Pushing & should be reevaluated for A26
comment:5 by , 3 years ago
Keywords: | simple removed |
---|---|
severity: | → simple |
comment:6 by , 3 years ago
Keywords: | simple added |
---|
comment:8 by , 2 years ago
Milestone: | Alpha 26 → Backlog |
---|
Note:
See TracTickets
for help on using tickets.
(Note that this is a particularly bad problem in MP, because 500ms turns means that timers fire almost every turn for each entity, meaning there is very little 'smoothing' effect from doing X% of entities every turn, unlike in SP where 200ms turns means that any individual turn is faster even if the total computation cost isn't decreased).