Welcome to the Second Life Forums Archive

These forums are CLOSED. Please visit the new forums HERE

Sleep less server intensive than Timer?

Adam Ramona
Registered User
Join date: 5 Jan 2005
Posts: 56
02-03-2007 05:39
I interpret the excellent lag page on the wiki to be saying it is less server-intensive to use llSleep instead of llSetTimerEvent. Is that correct?

So, saying:
CODE

float angle = 0;
default
{
state_entry()
{
state gotoRotator;
}

}
state gotoRotator
{
state_entry()
{
llSleep(0.1);
state rotator;
}
}
state rotator
{
state_entry()
{
angle +=5*DEG_TO_RAD;
rotation rot = llEuler2Rot(<0.0,0.0,angle>);
llSetRot(rot);
state gotoRotator;
}
}

would make less demand on the server than saying:
CODE

float angle = 0;
default
{
state_entry()
{
llSetTimerEvent(0.1);
}

timer()
{
angle +=5*DEG_TO_RAD;
rotation rot = llEuler2Rot(<0.0,0.0,angle>);
llSetRot(rot);
}
}

Is that correct?

Regards,
Adam
Adam Ramona
Registered User
Join date: 5 Jan 2005
Posts: 56
No news is good news?
02-03-2007 18:03
Well, nobody's replied (do I get a prize for that?), so I'm assuming that since nobody's jumping in saying "my god, you fool, don't do that for this obvious reason" then it must be okay, so I'll go ahead and use this technique for rotations from now on (yep, I use a lot of rotations :)

Can anyone tell me how I might measure accurately the difference between one using a timer and one using sleep? Or is it a matter of empirical observation?

Cheers,
Adam
Lee Ponzu
What Would Steve Do?
Join date: 28 Jun 2006
Posts: 1,770
02-03-2007 20:35
I don't really have an answer for the specific efficiency question.

The big difference between the sleep method and the timer method has to do with handling other events. When the script is asleep, I don't think it will get any kind of external event, such touch, move, listen...

With a timer, it will get those events.

In side most OS's, a sleep and a timer are not very different. Of course, LSL and the sims are not Most OS's.

Edit===
Well, if sleep is a busy loop, then you have a classic trade off. For a very short delay, sleep will be more efficient. For a longer delay, a timer will be more efficient. If all sleeps are busy loops, then I would avoid them unless they are very short.

BTW, I did some experiments with timers. They are not very accurate. That is, a timer that goes off once per second might be off by quite a bit. (No time to tabulate precise data, and it will depend a lot on what else is in the sim.)
Stylez Gomez
Union Micro
Join date: 4 Jun 2004
Posts: 146
02-03-2007 23:01
I believe in the Mono presentation that a couple of the LL devs did for a Microsoft conference of some sort stated that scripts that use sleeps instead of timers are more of a burden on the servers.

Watch the presentation:
http://download.microsoft.com/download/9/4/1/94138e2a-d9dc-435a-9240-bcd985bf5bd7/Jim-Cory-SecondLife.wmv

I watched the video a couple of weeks ago, so I'm not sure how accurate my information is... you might want to look at it yourself to get the info first-hand.

Besides how much stress they put on the sim, I personally think timers are a better way to go. When your script is sleeping it won't trigger any events, they will all sit in line waiting to trigger when the script wakes up... then they all trigger at once. At least with a timer, all events can trigger on their own accord while waiting for the next timer event.
_____________________
Adam Ramona
Registered User
Join date: 5 Jan 2005
Posts: 56
02-04-2007 00:21
Thanks for the pointer Stylez. The fellow does indeed seem to be saying that a timer is a better choice than a sleep, because a sleep-based script is essentially an infinite loop. I'm not programming-savvy enough to fully understand the implication.

Your other points about the differences between timers and sleep are well taken as well. Do you think the wiki page on lag is misguiding? Should it be changed?
Lee Ponzu
What Would Steve Do?
Join date: 28 Jun 2006
Posts: 1,770
02-04-2007 08:23
From: Adam Ramona


Your other points about the differences between timers and sleep are well taken as well. Do you think the wiki page on lag is misguiding? Should it be changed?


Certainly worth a comment in the wiki, with a link to the video. Don't make a definitive statement, just say something like, "In some cases, timers might be more efficient that sleep, and vice versa. "
Gaius Goodliffe
Dreamsmith
Join date: 15 Jan 2006
Posts: 116
02-05-2007 03:45
Obviously if you want to receive and handle other events, you need to use the timer. OTOH, if you don't handle any other events (say, "state_entry" is the only function in your state, so you're not going to get any events queued up for you anyway), llSleep seems to be much more accurate if you're attempting to sleep for a specific duration. I tried doing a multi-move sort of script using timer events, and one using an infinite loop with llSleep instead, and the latter is significantly/noticeably/visibly smoother. In short, use timer if you need something done periodically every so often, give or take, whereas use llSleep if you need something done at specific intervals. Don't use timer events if the actual timing is an issue.
Talarus Luan
Ancient Archaean Dragon
Join date: 18 Mar 2006
Posts: 4,831
02-05-2007 10:29
Well, in your example, you are doing something also which is known to be horribly inefficient: State changes. State changes are on the order of 10x less efficient than using a state variable and conditionals to change script operation within the same state. While states are nifty cool things from a programming design standpoint, they exact a heavy performance penalty for constant use. They are fine if the state changes are few and far between, but that example you gave would be fairly hideous, changing states many times a second.

As for llSleep being more/less efficient than a timer, I don't think they are significantly different. Internally, llSleep is probably modeled on some kind of timer anyway. In both cases, the script is not normally active during the specified time period. llSleep does have the advantage that the script will not even execute events while it is sleeping, whereas a timer will still allow events to execute while the timer is running. As such, there is a trade-off. If you want to force the script to be idle no matter what, at the expense of being unable to respond to events (which could cause events to get lost if you are receiving more than you are processing) in a timely fashion. Otherwise, just use a timer.

Really, they are used for different reasons, and you have to understand the effects of using one or the other before making the decision to use either.
Adam Ramona
Registered User
Join date: 5 Jan 2005
Posts: 56
02-07-2007 14:28
Thanks for the info re states Talarus, I had no idea. Somehow I had built up the idea that it was preferable to use states rather than change variables. Seems like, for this example, the timer version is the better choice.
Osgeld Barmy
Registered User
Join date: 22 Mar 2005
Posts: 3,336
02-07-2007 21:22
alot of ppl find it more readable or ezier to control than having (lets say) 1 varible named mode and 32 different modes, even when working with your own scripts you can quickly cross modes (vstates whatever you wanna call them) or just plain ol loose track of them

course theres this wonderfull thing called comments, i usually write my scripts as a "solid state" and if they get complex a nice chart outlining all the modes and some coments pointng out the changes within the script saves ALOT of headache