Spring RTS Engine

Spawned about 700 units in 88.0 (develop) and noticed (via Alt-B) this function was using about 60% cpu. The odd thing is this was constant regardless of whether any units were actually moving (all units on stop order).

I don't know much about what this function is really doing but it seems like a good candidate for optimising, especially where stationary units are involved.

Any thoughts on why this uses so much CPU? Is it a bug?

I can't explain the difference but I did discover that by disabling HandleObjectCollisions(); on line 253 of GroundMoveType.cpp I was able to add 1500 units with an Unit::Movetype::Update CPU usage of under 5%.

I have no idea why my usage is different to yours but reasons could include:
* Processor is only a Dual-Core Pentium D 3.00Ghz
* Compiled with OMP
* Using map: GRTS_River_Valley_1.4
* Using game: Balanced Annihilation V7.63

1500 units of which type?

Collision handling gets more expensive when more units are packed into the same or smaller space (because the quadfield resolution is fixed --> each quad will have a higher load factor), so N fleas > N bulldogs.

When I reported the bug I was spamming peewees (from a factory to a waypoint). After disabling the collision check I spammed core raiders (via cheat).

To get a better comparison I just spammed 700 peewee via cheat (collision check still disabled). CPU usage of Unit::Movetype::Update at 2%. Moved all units and CPU usage of same function jumped to 40-50%. At end of move the usage dropped back to 2%.

i can confirm this with 88.0. i was spectating online games, and at some point, whne it started to lag, i checked Alt+B, and saw the same thing; Unit::Movetype::Update beeing very high.
it was latest BA, and i have 4 Core AMD Athlon II with.. i think 2.6GHz or something. yeah... not really accurate/usefull info, just saying...

@Spliff, there is no 88.0 on branch develop.

Done some more tests.

GroundMoveType.cpp::HandleObjectCollisions() is where the high CPU usage is. Within that HandleFeatureCollisions() seems to use the most CPU, followed by HandleUnitCollisions() and collider->Block().

The interesting thing about HandleFeatureCollisions is the CPU usage does not appear to depend on the number of features on the map. I tested this by checking the CPU usage before and after reclaiming all the trees on GRTS_River_Valley (trees are basically the only features on that map and there is maybe 100-200 trees). There was basically no change in CPU. I find this rather odd because with no features the function shouldn't doing much except for qf->GetFeaturesExact(...).

I made some changes to where HandleObjectCollisions was called. I was able to get a major speedup by checking if a unit "hasMoved" before checking for collisions.

It seems to work quite well except in some edge cases where units abort their pathing either too early (giving up while pushing through crowds) or too late (endlessly bumping around the goal). I tried to compromise by also calling HandleObjectCollisions on slow updates but the units still give up too easily.

It seems to me the real issue here is that units struggle to accurately determine whether they are temporarily or permanently stuck. It seems that by calling HandleObjectCollisions for all units you get better behaviour in crowds but only at the expense of a constant and significant CPU hit.

I'm going to have a closer look and see if I can't find a way to deal with the underlying issue of detecting and handling blockages.