How much load do listeners create on a sim?

Hi all, Im a longtime programmer but new to SecondLife's lsl script. I have a couple of questions in relation to best practise for listeners...

How much of a performance hit do listeners cause to a sim? IE: I will potentially have about 20 lights on my property which I wish to switch off during the day. Now as I understand lsl so far (and that is about 3-4 hours worth) i cant directly address an object like in javascript etc (root.objectName.action) and make changes to its parameters correct? So I would need to make each light listen on a channel for a certain string to be broadcast to the channel in question. This means twenty listeners running all the time which isn't normally a high number in C, PHP etc, but someone mentioned to me that this would create quite a load for a sim in SL?

As I said Im new to lsl so perhaps you CAN address an object directly in which case someones enlightenment would be greatly appreciated Cheers all..

I sympathize with your concern about the sim load As long as LL do not provide some useful measures to decide the load I would not worry too much.
When that is said, the use of filters will reduce the load and a low traffic channel will reduce it.
Use the key and/or name of the talker as a filter and use a big negative number as channel number.
See:
http://www.lslwiki.net/lslwiki/wakka.php?wakka=llListen

the old addage that "open listens cause lag" is still probably true, but probably such insignificant amounts of lag as to be pointless. I don't have any solid data on this, but listens don't feel like the problem they were back in '06.

The main problem is having unfiltered listens on channel 0. Because unfiltered listens trigger everytime, anyone or anything speaks within range. Even if you later screen that listen for keywords and such, it's still running that logic every time someone speaks.

The best practice, is for every listen, include a handle, and use llListenRemove to close listens when you no longer need them.

If you do need them, then you need them, and there's not a lot of getting around that. If your throw is more than 100m, use llRegionSay. Avoid using "common" channels. (13, 69, 99, 100, 999, 1000, etc) and whenever it's just scripts talking to scripts, use negative numbers.

HUDs for controlling attachments, and inter-attachment communications hardly ever need more than 10m, so use llWhisper.

Let's look at your light problem. I have a similar project going in my sim. Choose a single channel which all lights obey.

llListen(-243231, "", NULL_KEY, "lights off";
llListen(-243231, "". NULL_KEY, "lights on";

These two listens will only trigger if their specific commands are said, regardless of who said them. You could do it with one, unfiltered listen, and screen the results in the listen event.. I'm not sure which way is "worse".. and I'm not really sure it matters all THAT much anymore.

in your listen event, this line is magical.

if (llGetOwnerKey(id) != llGetOwner()) return;

This means, "if the owner of the object that is speaking, isn't the same as my owner, end event". Avatars(agents) own themselves. So that listen will not fail if you speak, or if any object you own speaks.

Then it's just a matter of doing the old "if (message == "lights off" and so on.

OK - so I have a bunch of lights that switch on and off automatically by checking llGetSunDirection( ) within a timer with a llSetTimerEvent of a few minutes.

Does the timer consume resources continuously and if so how does this compare to a listener?

Where I'm heading is - which is more efficient? Having each light have its own timer or have a master timer and have each light listen for a command from that.

Rime

Thanks for the advice Dora and Winter! Will adjust my scripts as mentioned and see if Script Time improves a little. Im not suffering any noticable lag at the moment but it will be interesting to see the improvement Cheers again.

Try adapting this!

//** The original 'free' version of this script came from THE PARTICLE LABORATORY. **//

// EFFECT: Checks sun's position once a minute to see if it is NIGHTTIME.

// SETUP:  Drop this CONTROLLER TEMPLATE script into the same object with
// your PARTICLE TEMPLATE.  It will detect day or night in 60 seconds.

integer ON_AT_NIGHT = TRUE; // Set to FALSE for on during the day & off at night.

vector sunpos;
integer mode;
integer last_check=-1;

string  CONTROLLER_ID = "A"; 

default {
    state_entry() { 
        // Don't be a lagtard!  Checking more than every 60 seconds is greedy:
        llSetTimerEvent(60.0);
    }

    timer() {
        sunpos = llGetSunDirection();
        
        if ( sunpos.z < 0.0 ) 
            mode = ON_AT_NIGHT;
        else 
            mode = ! ON_AT_NIGHT;
        
        if ( mode != last_check ) {
            llMessageLinked( LINK_SET, mode, CONTROLLER_ID, NULL_KEY ); // send command
            last_check = mode;
        }
    }
}

I think it really depends on what you're doing inside the callback event. Like, if a sim has 1000 timers going but they're all really simple, it will be cheaper than 100 listeners that trigger really complicated scripts. And, likewise, 1000 listeners that trigger some really simple code will be cheaper than 100 timers with lots of tricky scripting behind them.

In other words, I think the sim code that runs _before_ it hits up the scripts is probably pretty efficient. Unless you're REALLY abusing it, worry more about what the scripts themselves are doing.

OK Meade - that I understand but in the given scenario where the resulting action is the same - toggle a few prim attributes - which is the most efficient?

1 timer and 99 listeners or 100 timers?

NB - I posted the same question in its own thread and plan to do a real (virual) world comparison of the two approaches and report back. Once I figure out how to take meaningful measurements of region performance

Thanks
Rime

Agreed 100%. It's what is in the listen() event that is the time eater. When doing some benchmarking for Mono Testing, before it hit the main grid, I tried to induce sim lag by opening a lot of listens. A lot. I think I opened about 75,000 before I gave up because I was unable to produce any substantial lag that way. The listen itself doesn't cause a lot of overhead, it's the processing of the event by your script that does.

Best advice, reject events as much as possible, and exit your handler as quickly as possible.

I'm not a scripter (I want to learn) so this might give you a laugh. Can you not link all the lights, even though they are apart from one another, and put the script in the master prim?

They will probably be too far apart. Also, if you moved one, they would all move.

If this were a chandelliere, this would be a good idea.

I'm still learning too but your suggestion is a good one for nearby objects within the link distance limits. In my case I have objects on land that is spread over an entire region so they can be a long way distant from each other.

Rime

I'd probably have one region-singular script that checks the sun position every 5-10 minutes and does a llRegionSay at interesting times: itsNowDay, itsNowNight, itsNowDusk, itsNowDawn, etc.. Though if you're really rabid about performance, you'd make the start of the strings unique instead of the ends.

Once you get that done, you can have any kind of time-aware slave scripts you want. Streetlights, maybe shops that open/close their doors at certain times, pool open/pool closed, etc, etc.

On a mostly-idle region, I don't think you'll really see much performance difference between this and having each object be stand-alone unless you've got a whole bunch of these objects ( >50? >100?) or the timer is running at some sillly rate like more than once/second.

Darien is right, IMO - best bet is to let the sim do the work and return from your script as soon as you can.

Meade and Darien - thank you for the additional insight.

As I noted in my other thread I will try to benchmark both approaches for my own region and report back the findings. Though it may be, as you suggest, that for a small number of objects the difference is minimal.

I use the day/night technique for lights and ambient sounds (ie songbirds vs owls) and can think of a few other uses. Would be nice to have a dedicated channel for system generated announcements that scripts could respond to

Rime

you're welcome ;p

Thank you

I use the Particle Laboratory script suggested by Tyrehl above with the timer even set to 180 seconds because I'm not fussy if I bumble around in the dark for a bit.

There are 20 linked sets throughout the building, each with its own script checking the sun's position and I'm thinking of adding perhaps as many again (although no more than say 3 in any room - I believe even the best graphics cards are limited to no more than six light sources at a time).

Am I right in thinking the llMessageLinked function is more efficient or should I still explore Meade's llRegionSay suggestion?

llMessageLinked is faster and less laggy, so long as your lights are all part of one link set.

I don't think that checking the sun position is overly expensive on the sim - it's more a qusetion of how often your scripts are running. For a big link set, I'd probably favor putting the brains in the root prim and using link messages just to keep it so that you just have one script polling the sun and the rest of the scripts only getting woken up when they have something to do.

Also, the 6-light thing is an OpenGL limit, I think - doesn't really matter what kind of card you have..

edit: and yes, link messages are a lot faster than chat messages, though there's probably cases having a 250-prim object with scripts in each prim where it might be cheaper to use chat.

So I guess I should link as many lights as possible to a 'sensor' prim holding the switch script and minimise the number of scripts checking the sun's position that way?


I stand corrected. It was quite some time ago that I read this so I'm not all surprised I got it wrong from memory. However, the principle of controlling the number of visible light sources holds true given that SL runs on OpenGL?

Thank you both for your replies.

That's an option but I wouldn't kill myself squeezing every last computron of performance out of this. There's a line there somewhere where it's better, IMO anyway, to keep stuff managable and just eat a little of the performance overhead..

It's a never-ending problem with all programming - there's always lots of different ways to solve most any problem and you have to weigh the trade-offs between things like complexity and performance.

Thanks, I can understand that. Perhaps I'm a little over scrupulous about checking these things because I'm never quite sure what I'm doing. For what it's worth, I have noticed that the lights do not switch on at the same time in different rooms - not that this is a serious visual malfunction since I quite like the random nature of it - but perhaps that might be just as much to do with the timer and the moment each script was set as a bottleneck of scripts checking the sun's position every three minutes.

As for manageability, I'm quite careful and organised about my building so it would only take a minute or two of my time to link the prims together.

heh the exact question I just proposed in the other thread (before reading this one)

link limits are going to make this hard... sadly I think this is a case where the new script limits may actually hurt sim health, because it's obviously less running code to use the master control and listen method, but may not be as healthy for the sim to have that many open listens... there's a chart on the lsl Portal under the efficiency link that compares listens on different channels, low traffic channels have the lowest impact based on that listing.