timer or llSensorRepeat

Okay, from a PURELY efficiency/sim stats standpoint, which is nicer to a sim and it's performance:

llSetTimerEvent(60);
timer(){ llSensor(blahblah); }

or

llSensorRepeat(blahblah, 60);

?

My script can go either way, and I wanna do it the "good" way. Timing accuracy isn't terribly important in this application, it's a "check to see if another object is still in range" sweep.

I'd just use a sensor repeat. 1/2 the number of events to process.

definatly

Also a bit more readable in your code IMO, and can offer the possibility of detecting agents/avatars in neighboring sims if that is desired.

However, there are situations when calling a sensor from a timer makes sense. If your sensor's arguments change a lot, then it's probably better to call llSensor from a timer than it is to call llSensorRepeat whenever you change any of the arguments.

Why? Either way, you'll have to call llSensor/llSensorRepeat when the arguments change. There extra cost of the call on llSensorRepeat shouldn't outweigh the cost of the timer running unnecessarily. In particular, llSensorRepeat doesn't require running your script every cycle, the way a timer doesn.

On the other hand, if there's some other reason for keeping the timer, then calling llSensor from the timer could make sense.

Yes, by having less llSensorRepeat calls, you'll waste less memory.

if the timer isn't being used, I actually prefer that method, since sensor repeat will occasionally grab references to targets across sim borders, or on the sim edges even if they are well outside the range of the sensor... with little rhyme or reason and may bork data if you are relying on a particular range (I've grabbed people that were 500m+ away on a semi regular basis if they were on the sim edge or across the border.)

also I can't recall if sensor repeat will jump states, but the timer does, and can be used to run different types of sensors in different states, without a new call to set it up.

Are you saying there's a memory leak in llSensorRepeat?

Bugs and anomalies in a function are good reasons to avoid it.


I believe llSensorRepeat will survive state changes.

But the point about having different types of sensors doesn't make sense. You'll still need a new call on llSensor to set up the different sensor.

By having llSensor in a timer event with arguments of global variables, you can change it on the fly without calling llSensorRepeat each time you change any of the variables. Removing the timer and adding llSensorRepeat calls in possibly several places would cause larger memory usage. I'm talking about compiled bytecode, not memory leaks or anything. The code itself takes up space, and space can be precious.

Either you or I are missing something obvious.

If you're only calling llSensor from within the timer event, then you can equally as well only call llSensorRepeat from within the sensor and perhaps no_sensor events. So it would never be more than three places. Conceivably, putting the call into a function could save more bytes.

The timer approach, on the other hand, adds a call on llSetTimerEvent plus it adds a timer event handler. Does the additional event handler for the timer and call on llSetTimerEvent use less memory than the two or possibly three calls on llSensorRepeat? Obviously, the need for the no_sensor event, or other needs for the timer event could affect which one wins in any particular situation. But the timer approach never gives you the option of not running every cycle.

With both a sensor and a no_sensor handler, you'll get an event every period on llSensorRepeat() as well. However, note that llSensorRepeat() may save something in the queuing of event (logic), whereas repeated calls to llSensor() might be more expensive in terms of event registration, as well as the second actual event call. Eh. Might be worth asking the Lindens which is likely to be more expensive. I typcially go with whatever makes more readable, maintainable code, as I find that a much larger requirement over time than performance, at least for the typical application.

depends on how you set it up, if the call for llSensor is in a function, then yeah you have to re tweak it... if however it's buried in the timer event for each state, then you'd simply specify it differently for each state.

as for absolute byte code, sensor repeat is going to be cheaper, but not by a ton.

although I have abused the repeat function for a second asynchronous timer, I didin't note if it was as stable, or less so than timers.

as far as event queueing goes, if the sensor call is the only thing in the timer event I can't imagine it being much different in overall effeciency of running commands. maybe a hair...

the option of adding decision logic into the timer with the call is a bonus, as is the exclusion of extraneous results with the timer method.

sometimes you want to pick up anything possible though, and the repeat method is better for that as well as when the timer is otherwise in use.