Which causes less server load?

Which of the following would cause less of a server load:

1) A single prim with a 0.5 second Timer event making 2 llMessageLinked calls during each tick, or

2) 3 prims, each with 0.5 second Timer events, but making no llMessageLinked calls at all.


Basically, I have an object where 2 prims do something exciting and the root prim manages it all. I'd like to code the object to be as server-friendly as possible, but I don't know which method that would be.

Any help?
-Ryas

In principle, a script should never get a single cycle while waiting for a timer to fire. I actuallity, I don't think that has been shown to be true.

Does the "master" always send two messages when its timer() event is called? If not, having a master on a timer would probably use less than three timers because the three scripts are only leaving their idle state when needed. You'll also get better synchrony with the master as the llSetTimer sets a minimum bound on the time before timer() is fired, and three clocks would probably drift over time.

My intuition is that the code simplicity would swamp any minor differences in event structure.

Yes, the master prim always sends two messages during the timer() event.

If I were to use three timer() events, all three would run to a set period of time, using llGetGMTclock(), so they would all turn off at roughly the same time (depending on how accurately the timer event is behaving). And it's not necessarily important to have exact split-second timing between the prims.

The "flow" of my object's behavior seems smoother using three clocks, rather than using one clock and llMessageLinked(). But the code is cleaner the other way. I just wasn't sure if one method produced significantly more server load than the other.

Thanks for the help.
-Ryas

Setting a timer event in and of itself is relatively low cost. You're just specifying a slice of time after which your script is going to do a specific set of instructions. I would think that the "server load" question only really comes into play when the code inside the timer() event itself is executed. With option 1, you are adding an additional function call just to tell the other scripts to do something. With option 2, they just do it. I don't think there is much optimization to be done until the timer actually fires and you start doing stuff.

If possible you want to average the sim loading by using non exact timer numbers. Keeping peak Sim loading down helps.

Hadn't thought about that, but it makes good sense!