CPU load from 'Events'

[THobson]

There is some behaviour I want to cause that can be done by adding an event to every unit in mission.  This is giong to be a very large mission.  Does anyone know if adding an event to  a large number of units will increase the load on the CPU?

Edit:  I should add that the event is the 'killed' event.  So it will not be executed more than once per unit.

[Artak]

Event based conditions are check at a very fast pace and it will add strain to the CPU.

Do a test. Insert a radio trigger that covers the whole map and use it to add the event handler to every unit.

[THobson]

Thanks.  Pity.  I will need to think of another way to do it then.

I have a trigger that fires at the start of the mission that puts the event handler on every unit - but this is at the very early stage of creating the  mission, so there are not many units around yet and any impact on performance will not be noticed.

[Korax]

Eventhandlers do not cause strain on the CPU, they are not 'conditions' being checked at a regular intervolt as some would think, these are simply extra commands attached to certain events of a unit. So if you give a fired EH to a unit, when he fires a gun not only will it fire, but trigger that event. The eventhandler isnt 'checking' every millionth of a second whether the unit has fired or not, the event simply triggers when the unit has fired or been killed.
So you can have 700 units in a mission, each with a fired, killed, and dammaged EH with no extra cpu load then you would have with just 700 units.

Just wanted to clear that up, this was confirmed by Suma (OFP lead programmer) on the BI forums a while back.

[THobson]

Hey that is good news.  I will stick with it.  Thanks

[Artak]

Well that's totally the opposite of what I've seen written about EH's in this forum   If it came out of Suma's mouth I'll believe it. Maybe I should visit the official forums more often. Thanks for correcting this Korax  

[Zayfod]

Please post the link to Sumas comment.

The ECP project can confirm  that an increase of EH allocation does increase cpu load substantially. Our EHs are added via config to every unit placed on the map and our results show that the more EHs used the higher the strain. These tests were conducted with zero scripting activity and zero engagements. Very high unit numbers were used.

Zay

[Killswitch]

The ECP project can confirm  that an increase of EH allocation does increase cpu load substantially. Our EHs are added via config to every unit placed on the map and our results show that the more EHs used the higher the strain. These tests were conducted with zero scripting activity and zero engagements. Very high unit numbers were used.

Can you describe this test, in a rather detailed way? (The setup, how you tested and based on what you made the conclusion that EH:s are substantially adding to the CPU load). Also, can I recreate the test using ECP 1.072, the currently publicly available dev version? Just curious...

[Zayfod]

Sure thing  

one of the tests I personally did and can confirm was when we introduced 2 new EHs in the main config. A getout and incoming missile EH.

Both are now in the class ECP_Eventhandlers, along with the others being:

Init, Hit, Killed,and Fired.

The test was rather simple really, however I made a point to run it on a low spec system (As I test all ECP updates on). This was a PIII 650  with a matrox g400 32MB card.

I placed 30 x groups of 6 AH1s on desert island, all landed and still. All west units. I simply ran around and tested fps  with and without the 2 new EHs. (getout and incoming missile).

The results were profound enough that Fraps was not even required.

With the new EHs included fps was down by approx 2 - 4 fps, but the major issue I had was not the fps but a consistant pause that occured every 1-2 seconds or so (Note this was only because I was pushing this old PC to the max). I did the test at least 4 times as I recall, the results were the same each time. Performance was degraded by the introduction of the 2 new EHs.

Faster machines will be more difficult to test with, thats why I always have the old gal handy for these tests.

Zay

[Killswitch]

EDIT: Found Suma's comment on CPU impact of EH:s See the thread Multiple scripts run from one event handler. Flip to page two of that thread and some ways down, Suma answers "The Sharpshooter" with:

(The Sharpshooter) "When I add an EventHandler to a unit(in the config.cpp) this means it will run the script the whole mission. Adding multiple units that have eventhandlers attached + all the scripting the mission will have and the units, ect. will make the mission heavyer, wonÂ't it ? I mean much heavyer, or the EventHandlers donÂ't use much CPU ?"

(Suma) "It really depends on what event are you talking about. Properly implemented event handlers have nearly zero overhead, because they are executed only when even(sic!) is detected.

If you are talking about permanent script started from "init" event  handler (or from any other handler), then yes, there will be exactly the same overhead with this script as with any other script. Be sure to use at least ~0.001 trick to if you need to use permanent scripts."

My own testing

Setup: OFP 1.96 with ECP 1.072, DR config, edits made to ECP_EventHandlers for testing.

Description
I have tried something similar:  150 Cobras on desert island (30 x 5) and me as a West "Officer" unit running around. I fail to see a difference between just having the ECP init EH present and having all of them there. This is using the 1.072 dev version of ECP with the DR config variant. (Binned using cpp2bin)

After 20-30 secs, I am pegged at 2-3 fps no matter if ECP_EventHandlers contain only the init EH or all of them (which doesn't include the getout handler you had.)

This is using an Athlon XP 1900+, 1 GB PC2100 and an ATI 9600. OFP was loaded with "-nosplash -nomap -mod=@ecp" and I  have my OFP\Addons and OFP\Res\Addons entirely clean of any third-party addons.

View distance was 500 m, terrain detail to "Very low". @ECP\ECP_Settings has one change only:ECP_override="low".  I am amazed at how a 650 Mhz CPU and an old Matrox card can run what you described... or my compy/OFP settings are worse than I have thought  ;D

In my experience, adding EH declarations in configs are generally quite low-impact.  Of course, there are zillions of addons out there that then use the EH system badly, say by executing heavy scripts in the fired EH, which is a high frequency event. Furthermore, its quite common with an init EH starting a heavy monitor script that eats up CPU real quick. From digging through ECP, I suspect that's where the CPU cycles are going.  NB: ECP is far from the only addon/mod that does that. In many cases, what they do is work around what is IMHO one of the great showstoppers of OFP: The killed event is not broadcast. Why that wasn't fixed way back is truely mind-boggling...  

ECP_EventHandlers used in testing
"Light":

Code: [Select]

class ECP_EventHandlers
{
        init="_this exec {\ECP_Effects\init.sqs}";
};"Heavy" (Standard ECP 1.072) version:

Code: [Select]

class ECP_EventHandlers
{
        init="_this exec {\ECP_Effects\init.sqs}";
//   init="_this exec {\@ECP\Addons\ECP_Effects\init.sqs}";
        killed="_this call ECP_EH_handler_killed";
        hit="_this call ECP_EH_handler_hit";
        fired="_this call ECP_EH_handler_fired";
        IncomingMissile="_this call ECP_EH_handler_incomingmissile";
};
Test mission attached below:

[Zayfod]

Hey thanks for getting Sumas quote

Ok cool,
I will test again. Will have to blow the dust off the old girl and fire her up.

Zay  

edit: Haha, *slaps meself*   . Well, hats off to you mate. I was unable to reproduce the consistant pause effect I had ages ago when I first did this test. Old gerty must have been playing tricks on me. Using 1.92 BIS patch as I recall. So I guess this is all good news  .

Nice sleuthing Sherlock.