Event Firing Rates Test

heyas;

i was curious about different scripting methods (for aos and rideables and such) for testing avatar movement, speed, and suchlike. i've always suspected that using a timer was less laggy than using other events (like control. or like moving start; did you know, it fires off multiple times while you are walking). so, i devised a test.


(script posted below, unless it happens to contain secret code words that the fool board doesn't allow.)

//////////////////////////////
//-- Script Firing Test
//-- by bloodsong termagant
//////////////////////////////
//-- wear this, then perform one of the tests
//-- ie: click and hold: must DOUBLE CLICK and hold
//-- or press back to test controls
//-- or move forward to test moving
//-- for ten seconds (until it tells you the count)
//-- tip: hold fwd or back keys while resetting to capture test event promptly
//-- (move starts to fire on some random animations)



integer c = 0; //--the count of how many times the event fires in the ten second period



default
{
    state_entry()
    {
      llRequestPermissions(llGetOwner(), PERMISSION_TAKE_CONTROLS);
    }
    
    run_time_permissions(integer perm)
    {
        llTakeControls(CONTROL_BACK, TRUE, FALSE);
        llOwnerSay("Back Key controlled and locked. Press Back to test control firing.");
    }

    touch_start(integer total_number)
    {
        llOwnerSay("Starting Touch Test.  Hold for 10 seconds.");
        state test_touch;
    }
    
    moving_start()
    {
        llOwnerSay("Starting Move Test.  Hold for 10 seconds.");
        state test_move;
    }
    
    control(key id, integer level, integer edge)
    {
        llOwnerSay("Starting Control Test.  Hold for 10 seconds.");
        state test_control;
    }
    
    
}

state test_touch
{
    state_entry()
    {
        llSetTimerEvent(10.0);
    }
    
    touch(integer tn)
    {
        c++;
    }
    
    timer()
    {
        state end_test;
    }
}


state test_move
{
    state_entry()
    {
        llSetTimerEvent(10.0);
    }
    
    moving_start()
    {
        c++;
    }
    
    timer()
    {
        state end_test;
    }
}


state test_control
{
    state_entry()
    {
        llSetTimerEvent(10.0);
    }
    
    control(key id, integer tn, integer cn)
    {
        c++;
    }
    
    timer()
    {
        state end_test;
    }
}


state end_test
{
    state_entry()
    {
        llSetTimerEvent(0.0);
        llOwnerSay("Count Reached "+(string)c+" in 10 seconds.");
        
        llSleep(10.0);
        llOwnerSay("Resetting");
        llResetScript();
    }

}

RESULTS:

the results vary, obviously. and i didnt do any actual mathematical averaging. i just eyeballed it! numbers are number of times the event fired in 10 seconds.
also, the speed/lag of the sim the script is running in has a big impact on the numbers.


Beta Grid:----------------------------------------

control test: 570 564 569 569 (~ 57/sec)
touch test: 270 272 (~27/sec)
move test: 234 238 244 (~23/sec)


Main Grid
Island Sim (with a lotta chickens)-----------------

control test: 289 301 277 (~29/sec)
touch test: 94 90 84 83 (~8-9/sec)
move test: 30 23 75 79 71 (~3-7/sec)


Island Sim with Script Bug Lag----------------------

control test: 351 357 329 (~35/sec)
touch test: 120 114 124 (~12/sec)
move test: 20 54 21 54 (~2-5/sec)


Class 4 Island Sim:-----------------------------------

control test: 187 200 197 (~20/sec)
touch test: 129 128 128 (~13/sec)
move test: 0 2 3 (0-3/sec) ???!



at any rate, a timer of 0.2 fires off 5x per second. 0.25 is 4x. though technically, i should have made a timer test to see how often it fires off, but a timer to test the timer... is kinda iffy.

You can use llGetTime() or llGetWallclock() or something like that to more accurately judge the beginning and end of your test. That might help for timers, though generally I think timers come off on time unless there is time dilation below 1 (and there's a minimum period of 0.05 seconds between ALL events).

In the test you conducted, one of the cases isn't like the others 'moving_start' is supposed to occur only when movement begins, and 'moving_end' is supposed to occur only when the object/avatar comes to rest after movement. So testing how often that event occurs isn't going to give you very lively results. As in, if you start in the corner of the region, move to the middle, and stop you SHOULD get one 'moving_start' event and one 'moving_end' event. You might get a couple more depending on how you move and what else is going on on the server, but it's not really expected.

As opposed to 'touch' and 'control' events that DO keep firing on their own when you have the control input held, as you correctly deduced. I'm not sure how much that depends on network traffic between the client and server during that period.

hewee;

ah, but you see... moving start and moving end fire off several times (sometimes many) during one 'moving' phase. which i discovered to my great annoyance several months ago. hence why it is in the test.

llMinEventDelay() is a very useful function when working with collision/control events where you don't need the script processing dozens of event triggers per second.

http://lslwiki.net/lslwiki/wakka.php?wakka=llMinEventDelay

Yeah, also these values can't really account for the lag produced by using one method over the other.

For example; if you want a wings script that opens the wings when you're flying, and closes them when you're not, then it's better I think to use control() to detect presses on the page-up/down keys, with a slow timer to catch people who use the fly button.

This way you can get a good reaction time from the script, without requiring a fast timer that triggers continuously.

In this case use of the control() event produces less overall lag, as it only performs working when either of the two keys is being pressed, which can be further reduced as DoteDote suggests by using llMinEventDelay. Whereas a continuous fast-timer is going to generate a lot more work for the script engine, especially under Mono since events are quite costly, more so than in LSO-LSL I believe.