IGlobalAI performance problem and other issue
Posted: 09 Aug 2005, 10:20
some random thought on the IGlobalAI...
I think there should be the possibility to "disable" some call runtime, to save cpu cycles.
That is: the code is in a dll, so it cannot be inlined, and it's virtual, so will cause a referenced slow virtual call, trashing L1 code chache on the cpu (data chache is already considered trashed, due the high unit count)
This is not a critical issue until a lot of units start to fight each other: then a lot of UinitDamage call are done (imagine a big shot on a lot of pewee), this (common) situation will introduce lag, specially if the UnitDamage contains heavy code, but also an empty function will do.
Another performance issue is caused by unit outside a group. If the AI manages internally unit groups, then finishing a order will call a lot of UnitIdle, introducing lag. For nothing, as the AI could take care for itself of idle units.
Neverthless, these are real useful construct and as to be mantained to provide a complete AI interface, but I think that there should be a "swich" in the CallBack to set that permit to disable these calling:
/**
* enables or disable the UnitIdle
*/
virtual void enableIdleNotify(boolean wanted);
/**
* set the minimum damage value that will trigger
* a UnitDamage call
*/
virtual void enableDamageNotify(float minimumdamage);
Another issue of the unit damage is passing the id of the enemy, wich permit to "cheat" accessing directly enemy position and type.
A thing wich is not clear on the documentation is wether a unit entering the los will trig also a EnteredRadar call (duplicaing calls)
I think there should be the possibility to "disable" some call runtime, to save cpu cycles.
That is: the code is in a dll, so it cannot be inlined, and it's virtual, so will cause a referenced slow virtual call, trashing L1 code chache on the cpu (data chache is already considered trashed, due the high unit count)
This is not a critical issue until a lot of units start to fight each other: then a lot of UinitDamage call are done (imagine a big shot on a lot of pewee), this (common) situation will introduce lag, specially if the UnitDamage contains heavy code, but also an empty function will do.
Another performance issue is caused by unit outside a group. If the AI manages internally unit groups, then finishing a order will call a lot of UnitIdle, introducing lag. For nothing, as the AI could take care for itself of idle units.
Neverthless, these are real useful construct and as to be mantained to provide a complete AI interface, but I think that there should be a "swich" in the CallBack to set that permit to disable these calling:
/**
* enables or disable the UnitIdle
*/
virtual void enableIdleNotify(boolean wanted);
/**
* set the minimum damage value that will trigger
* a UnitDamage call
*/
virtual void enableDamageNotify(float minimumdamage);
Another issue of the unit damage is passing the id of the enemy, wich permit to "cheat" accessing directly enemy position and type.
A thing wich is not clear on the documentation is wether a unit entering the los will trig also a EnteredRadar call (duplicaing calls)