more lagging research

more data based on the initial research in this thread:
/54/7a/16922/1.html

listens, repeating sensors, and timers that are quiessent (not doing anything) have an overhead cost.
active listen, repeating sensor, and timer events have the overhead cost, plus the event handling costs, and the scripts in the event handling costs.

things that have no (at least extremely negligible) overhead just by existing:
- physical scriptless prim (which is different from my initial results)
- one time sensors
- a scriptless prim

listen data
(number of object, sim fps)
(1, 9500)
(2, 9500)
(4, 9400)
(8, 9300)
(16, 8600)
(32, 7800)
(64, 5900)
(128, 3900)
(256, 2000)
(512, 1024)
(1024, 560)
(2048, 200)
(2304, 150)
(2560, 117)

timer
(1, 9900)
(2, 9500)
(4, 9500)
(8, 9000)
(16, 9000)
(32, 8100)
(64, 6200)
(128, 4100)
(256, 2200)
(512, 1100)
(1024, 550)
(2048, 200)
(2304, 165)

repeating sensor
(16, 9100)
(32, 8100)
(64, 6500)
(128, 4200)
(256, 2100)

mix of listener, sensor, timer
(16, 8800)
(32, 7600)
(64, 6500)
(128, 4100)
(256, 2000)
(512, 1000)

more as i run more experiments.

if you have a suggesting for a simple scriptiing test. drop me an IM.

thanks.

listen script:
integer myListen;

default
{
on_rez(integer start_param)
{
llResetScript();

}

state_entry()
{
llListenRemove(myListen);
myListen = llListen(0, "", llGetOwner(), "";
}

listen(integer channel, string obj, key ID, string message)
{
llSay(0, obj + message);
}
}


sensor repeat script:
default {
state_entry()
{
llSensorRepeat("", NULL_KEY, AGENT, .1 , PI, 10000.0);
}

sensor(integer total_number)
{
llShout( 0, "Hello " + llDetectedName(0) );
}
}

timer script:
default
{

on_rez(integer start_param)
{
llResetScript();
}

state_entry()
{
llSetTimerEvent(10000.0);
}

timer()
{
llSetTimerEvent(10000.0);
}
}

Let me state the obvious here and note that the amount of lag generated by timers and sensors is heavily dependent on the frequency that they run at.
I made four prims the other day, with a 1-second timer in each, and they lagged the crap out of the sim.
Also, if you have a lot of timers with a higher second count, and they are synchronized, you will experience short bursts of horrendous lag when they all fire at the same time.

Cool. The #'s on the mix are interesting. Did you get the time for the mix with 3 scripts or all in 1 script?

Similar to Eggy's comments on timers, there is another factor that must be considered when measuring sim impact of listens.

The impact of a listen is highly dependant on the amount of traffic on the channel that a listen is tied to. So a listen on channel 0 (the public chat channel) will impact a sim more than an identical listen on some other, presumably seldom used, channel.

It is the processing of the listen, as each message goes across the channel, that impacts the sim. Its not the listen itself.

- Ace

My theory on lag, as I was discussing with His Grace the other day, is that triggering any event, even if the handler is empty, lags the sim a little.
It just happens that things like touches are usually triggered once or twice, while timers, listens and sensors can trigger insane amounts of events in a very short time.
What on Earth is LL doing behind the scenes when an event is triggered?
Couldn't it be optimized a little? *shrug*

for listens & sensors some data does need to be copied. Listens would go into a stack. And sensor data would go into a specail data type. So it would make sense that for sensors on each pass would allocate a bit of memory then release it. Sensors would probably allocate a pointer to start then release it when it was finished. I couldn't say if a thousand concurrent threads chipping away at memory would cause this magnitude of lag. As for timers your guess is as good as mine.

true.

i think the thing worth noting here is that even if a time or listen or sensor isn't doing anything, it has an overhead cost associated with it.

a mix of objects with only one kind of script each

i agree with this theory, but i don't have data for it yet.