[Fwd: Re: [sldev] Possible solutions for alternatives to imposing
hard resouce limits for scripts (Was: Scripting Survey)]
Nik Radford
nik at terminaldischarge.net
Thu Jul 3 02:38:22 PDT 2008
(Forgot to post to the list)
> Nik Radford wrote:
> > However alot of the lag that was caused on sims was due to the poor
>> scheduling of scripts. Where every script was getting a minimum time
>> even
>> when they were idling. So the number of scripts present in the sim
>> became
>> an extremely active part how performance was effected. (correct me if
>> I'm
>> wrong however). I believe improving the scheduler will have a large
>> impact
>
> This is correct. I believe this was encapsulated in the "improved
> script scheduling" item.
>
> On the plus side, idle scripts are using less time now that CPUs are
> faster, an idle script uses about 0.0015 ms per frame on class 5,
> compared to 0.003ms on class 4.
Thats good :) Still the script shouldn't see any execution time if it's idle.
>
> This is still too much really, a few thousand scripts still cause
> serious CPU contention.
>
> This thread is sort of offtopic, we probably shouldn't let it grow too
> big.
>
I've changed the topic to show what I was hoping to discuss. Particually
the idea of handling scripts that are resource intensive. A resouce limit
suggests to me that the script may be stopped dead if it hits it. Where as
I believe it should just be denoted less excution time so as not to impact
the rest of the region, effectively giving the script a "time dialation".
Though only in extreme cases, where the scheduler can't really spare the
time to feed the scripts hunger. Of course if the script is the only one
in the sim, then the sim can denote all its allocated frame time (and
frames) to running the script.
The idea seems feasible. One question, that perhaps a Linden can answer:
do individual scripts get allocated the same amount of execution time each
frame or is there a larger total execution time that is split (like pie
:)) between all scripts on the sim?
Of course this is all bearing in mind that the scheduler is rewritten :)
Nik.
> -Jason
>
More information about the SLDev
mailing list