Multiple timers or master timer and listeners?

OK - I asked this in another thread but figured it wouldn't hurt to ask it in its own right.

Let's say you have ten street lights you want to automatically switch on and off with the Linden day.

Which is more efficient?

1 - Each light has it's own timer and checks llGetSunDirection( ) to determine night/day.

2 - A master light has a timer and uses llGetSunDirection( ) to determine night/day and sends on/off commands to the other lights which have a listener.

Thanks,
Rime

i would use a master timer and a listener. and if you use region say, the listener won't have to determine whether it's in range or not

a master system would be best, would keep the script time down and also the lag

Invisable box to determine the dirrection -> master changes state -> send message if something happend -> lights listen -> vise versa

OK - sounds like a master timer is getting the thumbs up.

I have a good amount of land in a pretty quiet region and have several lights and ambient sound packs dotted around that switch at dawn/dusk.

What I would like to do to round out this thread is to do a before/after comparison and that means getting some kind of benchmark data.

Searching the forums turns up a lot of discussion about benchmarking but nothing points to 'tool A'. Is there such a beast? Something that can be set up to monitor over a period of time and generate a meaningful benchmark?

If not, then I guess I could just park my butt somewhere and (with no other agents in the region or child agents) watch the stats. If that is the case - what are the best indicators?

Thanks
Rime

Hang on....

Which set of code do you want to maintain? Do you want to maintain a script that does everything it needs to? Or do you want to maintain two scripts, neither of which does the whole job? Which of these models is more useful outside your application?

My answer is: Timer in each script. Every five minutes, all lights will call llGetSunDirection() and do a math comparison. This means you can rez a light anywhere, and it works without any server setup. Surely that's worth something to you.

Well - if all I'm interested in is having various things change properties for day/night I figure I just need one master timer/announcer that does a llRegionSay on a dedicated large negative channel.

Then for whatever I need to be day/night aware I only have to drop a listener in and voila!

I think

I like the master timer, because all my lights click on at the same time.

I actually have a master clock in my sim, that operates the lights and changes modes on the environmental effects sound rocks.

So far, no ill effects.

Forgive this scripting dunce question:

Is there any difference at all for Scenario 1 between using separately compiled and/or LSL scripts as opposed to a single Mono compilation?

MONO has shared code space, so I'd assume MONO would be the better to compile to.

but here's a better question.... do multiple listens in all the lights have a higher impact than than multiple timers w/ checks against llGetSunDirection? running code-wise I'd say the former, sim health-wise I'm not so sure....

I was really wondering if, with the shared code, the Mono compiled scripts would still be multiple timers or if they would have less of an impact. As I say, I'm a scripting dunce and haven't a clue, so it's hard to even formulate a question.

Nope.. Only code is shared - a timer is more of something like a sim resource.

edit: consider this script:

list  gBunchOfNumbers;
default
{
     state_entry()
     {
          integer i;
          for (i = 0; i < 100; i++)
          {
               gBunchOfNumbers += ;
          }
     }
}

Most of the above is 'code'. The local variable 'i' in state_entry isn't and the global variable gBunchOfNumbers isn't - those bits are 'data'. With mono, only RAM (on the sim) used to store the code bits is shared - the data bits are still unique (unshared) for each script using this code.

So, if you have 100 copies of this script on a sim, they will all share the same code parts, the default state and the state_entry function, but each will be allocated memory to store it's own gBunchOfNumbers and, while state_entry is running, 'i' variable.



Yep. Unless you have a specific reason NOT to use mono, use mono.

I think it depends on what's being done when the listen or timer triggers. The sim probably has the sun position in some handy vector somewhere so doing a little math on that is (I'm guessing here) trivial. Assuming that's true, and that the listen case is talking on a unique channel, it comes down to a question of how many scripts want cycles and how often they're wanting them.

Thank you for the explanation. I didn't think it sounded likely, but until I asked I couldn't know. /me drools ;-D

Contrary to popular belief, there ARE indeed both stupid questions and stupid answers. Some say there are no stupid questions - I say these people aren't trying hard enough.

That wasn't a stupid question at all, Osprey. Not even a little. Hope I helped.

If the listen is on a channel that is only likely to be used for this application, I suspect the listeners will be much less impact than all the separate timers (unless you send out a chat message on each timer event--so if you go with the master timer, make sure to only send out a chat when things CHANGE, not every single time the conditions are checked).

Then again, if the timers run infrequently (say, every couple of minutes rather than on the order of seconds), it's probably not going to matter much either way.

If I were to take Winter's suggestion of a clock and make one for my hallway that used Ruthven's suggestion of llRegionSay to issue various messages throughout the day on Heewee's suggestion of an obscure channel such as -376219, would it be ok to set up a lot of different objects around my parcel that are independently scripted to listen for an appropriate message? Lights on, for instance at dusk, rainy window textures during daytime, front and back doors open first thing in the morning?

Or would it still be better to use a system of linked objects doing their own thing with llMessageLinked?


How would I weigh the implications of running code against sim health?

Also, if I want to compile to Mono is it just a case of 'Edit>Tools>Recompile scripts in selection>Mono' or alternatively ticking the Mono checkbox at the foot of a script window?

I've been doing this very thing for some time using llRegionSay. I have my light "sensor" check for daylight every minute and send out a message only if there's a change. It works great and is very low impact.

On a side note, I developed a club lighting system that works off the same premise and even with a couple dozen lights listening it's still a barely noticeable load on the sim. Any script that's in a wait state and doing nothing is going to be way more efficient.

I've seen timers bring sim performance down quite a bit. The more popular vendor packages have numerous scripts in them that do various things based on timers. If you have a few hundred of these vendors in the same sim you'll see a substantial performance drop.

run both systems and see which one has an affect on the sim FPS? there's no hard science on this one with the tools we're given.

the second answer is 'yes' either should work, assuming some odd mono bug doesn't crop up, although I think for the MONO shared code space to take effect, the scripts have to be copies of a single original, compiled in mono. scripts individually opened and saved don't get the benefit IIRC (no checking is done to see if another script already has the same contents). renaming the scripts that are copied though, should have no effect on shared code space (I think) so this can be used to reference different behavior (have the script check it's onw name to fill some variable or process some code against)

Thanks, Void, it's good to know that's more or less all it takes.


Does this apply for any script that is reused?

For instance, I use Seagel Neville's single prim sliding door script (/54/53/150641/1.html throughout my place and even though it uses neither llMessageLinked nor listen, there is a user-defined Init() function that defines the box primitive and hollowness features with llSetPrimitiveParams because these are key to how the script works. Seagel included extra features of transparency, size and so forth so that anyone could immediately see how his script worked by dropping it into a prim.

I use the Init() function to set different features from one door to the next - an oak grain texture here, colour and transparency there or tacky seventies style suction bumpmapping on the bathroom door. It's all stuff that can be achieved easily with the building tools but I have been in the habit of doing it this way since llSetPrimitiveParams was one of the first things I learned a script could do.

If I were to strip out all but the necessary parameters, which do not change, recompile this script in Mono and replace the scripts in all of the doors with it, would the copies take useful advantage of shared code space?

Correct, but it causes processing time for every object with a listen, according to the most detailed explanation I've seen about how listens work. Not processing time in the script, but system processing time figuring out which scripts to invoke.

In this case, since the "say" only happens twice a day, my objection is baseless here. Just pointing out that, if my understanding is correct, lLRegionSay() is not necessarily a cheap solution.

I wish I could find the detailed explanation, but it involved using chat logs, and whenever the system prepares to run a script with a listen, it checks the chat log and tests all the conditions.

Neither will afect FPS, even if there's hundreds of them. Unless you're thrashing, sims don't impact sim FPS.

This one has my vote, for simplicity and my best guess as to efficiency.

Timers themselves aren't expensive. Timers that fire too frequently, do too much processing, or are in too many scripts -- that's where the expense comes in. All three of these terms multiply, so you want to keep all of them reasonable.

A 5- or 10-minute timer would work just great. And just like RL, the lights wouldn't all go on or off at exactly the same time. That's a *feature*!

However, I feel that either solution would be quite reasonably efficient, and the choice architecture should be based on what behavior you want.

Nope, there are no stupid questions. It's not the question that's stupid.

Right. Any time a script is compiled, the object code gets an ID. All scripts with the same object code ID share code space. If you recompile a script, even without changing it, it gets a new ID for its object code, so space isn't shared.

For this reason, with Mono, for scripts that are likely to be in large numbers, it's best NOT to have user-editable configuration in the script, but to configure by notecard instead.

The best tool is a poor one, and limited to estate managers: the Top Scripts thing.

The reason it's a poor tool is it only takes a single sample. To characterize even a simple script, you need an inordinate number of samples.

/me reminds himself to open a JIRA to provide lowpass filtered numbers as well as the samples, and to provide this tool for parcel owners.

Thanks for clarifying that fab and groovy of feature of Mono, Lear. It seems like the principle of reusing the same texture as opposed to similar ones in order to help performance.

I guess I better make a start cleaning up the multiple copies of different scripts I have running on my parcel.