Babbage Linden asks: what can LL change in LSL to reduce lag?

Perusing Babbage's office hour transcripts, I see that he's planning to (or at least thinking seriously about) removing the 0.2 second delay on things like llSetLinkPrimParams in an effort to make stuff like resize scripts doable without being so painful on the sim. Or, rather, adding a llSetLinkPrimParamsNoDelayWootWoot or something so they don't break existing, delay-dependant code.

/me wonders what else they could do in the scripting world to reduce lag. Not talking big, huge, totally-redesign-everything projects (/me glares at Argent! ) but things that they could do relatively easily and would make scripting more efficient. Talking low-hanging fruit here.

Personally, I'd like to see:
- Better filters on llListen calls. It seems like I'm always checking for "is this my owner or an object owned by my owner" in the listen event handler. Being able to specify that (or some set of flags) in llListen, being able to regex object names, stuff like that would be great.

- A callback event when the animation state changes. Yes, Emerald has a built-in AO but being able to do one for all viewers (instead of constantly polling) would be even better until the base viewer code starts doing AOs client side.

- Being able to pass more than an int to on_rez. I frequently have to use chat to pass startup stuff to rezzed objects - it's a pain, it uses chat and it's slightly tricky to get the timing reliable. It'd be great to be able to pass a string or at least a key instead.

Anything else?

edit: /me will summarize in a notecard to Babbage in a week or 3. That or just point him here..


edit edit: JIRAs listed elsewhere in this thread, in no particular order:

http://jira.secondlife.com/browse/SVC-835: "Top scripts" for parcel owners

http://jira.secondlife.com/browse/SVC-1853: State of not-running scripts is not preserved over a region restart

http://jira.secondlife.com/browse/SVC-3895: Needs no introduction!

http://jira.secondlife.com/browse/SVC-93: llSetPrimitiveParams PRIM_ROTATION and llSetRot incorrectly implemented for child prims

http://jira.secondlife.com/browse/SVC-2654: Feature request: New function llTraceLine

http://jira.secondlife.com/browse/SVC-2885: llSetObjectScale() and llGetObjectScale()

http://jira.secondlife.com/browse/SVC-2885: H4 llPushObject applied to avatars is inconsistent

http://jira.secondlife.com/browse/SVC-2513: Push (llPushObject) not working correctly when applied to an avatar!

: add llSetLinkParticleSystem, please.

Well, I just created a display board that has 10 flip segments. each of the 10 segments has to have a script, plus the main controller script. I communicate what textures to set on what face and when the segments can flip. I can set the rotation of the prims with llSetLinkPrimitiveParams(), but there's no way to GET the link prim params! Nor is there an llSetLinkLocalRot() or llGetLinkLocalRot(). If I had these funcitons I could save 10 out of 11 scripts, or better yet (and this is my mistake), I could incorporate the main code into one of the segments along with that segment's code.

Short answer:
The more get/set link functions, the more that can be done without multiple scripts in the object.

Also, and I think this is more important than anything, and quite unaddressable.... There are far too many people out there who do not take system resources into consideration (because it's not their system). Re-sizeable hair with hundreds of scripts is ridiculous, and some jewelry has way too much bling (it's blinding at times). Probably 95 percent of the script load on a server is because of attachments that are poorly coded. I guess the only thing I can think of would be some sort of campaign by LL to encourage those who code to do so efficiently. Maybe some guidelines on how certain things should be approached, or even guidelines on what's considered an acceptable number of scripts for a particular function as well.


There's my 2 cents

The problem with llGetLinkPrimParams is that it'd enable people to make a really simple copybot script program. Yes, there are other ways to do that with LSL today but llGetLinkPrimParams would make it even easier..

I hear what you're sayin' but I don't think LL will implement it.

Considering all of the security holes which LL refuses to fix and so many other, easier ways to steal content which LL can not fix, it would be kind of ignorant to worry about llGetLinkPrimParams.

I remember seeing in one of the office hours where LL WAS going to finally implement it. It will do a great deal to help alleviate script load across the board.

llSetEffectiveLinkNumber(integer link)

After this call, until the next llSetEffectiveLinkNumber() call, or the end of the current event, all calls that refer to the current link will act as if the script was running in the selected link.

This is not a "redesign everything" function, honest.

llRegex() (see below)

llGetAttribute(string name);
llSetAttribute(string name, string value, integer permissions);

Local non-volatile storage. Get rid of all the hacks and extra scripts and things that people use to store non-volatile information and replace them with a small (maybe as small as 1K) name-value attribute store in a prim.

llGet/SetObjectAttribute(key id, ...);

Same as above, for other objects in the same sim, IF the permissions in the set attribute allow it.

on_set(string name)

An event called when attributes in the current object are changed by another script (in the object or outside it).

I'm not sure that regex on filters would buy you all that much over adding an llRegEx() call you could make within the function, even for LSL2 code.

Yes!

This could be implemented using something like the attributes mechanism, with a call to llSetObjectAttributes() in the object_rez() event.

Yeah, llGetLinkPrimitiveParams() would alleviate so many problems -- resizer scripts, for one -- and, as Jesse suggest, worrying about the copybot implications of llGetLinkPrimitiveParams() really is straining at gnats while swallowing camels.

You can, if you want to, write one just using llGetPrimitiveParams and a couple of other functions -- I won't go into details here, but it only took me a few minutes and a bit of research in the wiki to figure out how to do it, and I'm by no means the world's greatest scripter. My business partner and I use it, so all our builds end up with her as creator of all the prims rather than with some made by her, some by me, and some by our respective building alts.

Having llGetLinkPrimitiveParams() would make it a bit simpler and quicker, but it would still be even simpler and even quicker by far for the would-be content thief just to download a client or third-party program designed to do such things, and using a special client or program doesn't put the thief to the trouble and expense of acquiring a modifiable version of the item he or she wishes illegally to copy.

That minor disadvantage to llGetLinkPrimitiveParams -- that it makes it rather easier illegally to copy stuff in a way probably no one would bother to use anyway -- has to be set against the many advantages, in the way of convenience for the scripter and reduction in script activity generally it would offer.

One of the biggest problems in sims is too many active scripts. If they fixed SVC-1853 so people could stop and restart scripts reliably that would help.

If they fixed SVC-3895 so mono scripts wouldn't lag the entire sim on entry that would also help.

Actually if they fixed any bugs it would help, but apparently that's not going to happen any time soon.

a stroll through the hacks sections, and the "what can't you do in lsl" thread should provide tons of ideas....

every time we have to work around a limitation by adding scripts, or have to add a script just to get a certain piece of information that will only be reported in one place, to another place where it's needed.... that's where we lose cycles.

llGetLocalRotation, reported in a prim root, is the only place that info can be gotten, but is necessary to simultaneous move/rotate in child prims (thanks to svc-93) as an example....

set's without get's are another, requiring the user to track a variable internally to a script that is already being tracked in prim properties, but just can't be accessed, thus wasting memory and cycles, recording something twice just so you can monitor and act on it's current state.

there's plenty more, but that's just two example of types of problems in lsl that lead to inefficient design and wasted cycles

and FFS we need to do something about the mono insertion spike on newly rezzed object scripts... it shouldn't be so much worse than the serialization issue on border crossings (again mono)

letting us choose our default compiler. The "default to mono" is what's killing sims these days. All those mono resizer scripts pausing the sim 5-20 seconds..

definitely removing some of the antiquated throttles on things like llEmail and llInstantMessage. The goal was to slow down use of these functions. The result was people started using 10 "slave" scripts in every emailer or IMer. Sure, these can be used to grief people.. but so can a single 10m cube.

Outlaw and punish griefing, rather than punishing us all in a useless attempt to prevent it.

llGetLinkPrimitiveParams would be nice.. as would removing the throttle on Set... how about actively removing artificial limitations on llSetPos.. rather than forcing us to hammer setpos again and again in an attempt to move an item.

Some kind of per-object non-volitile text field. Maybe as small as 255 characters. Something we can use to store a modest amount of data. Not the name, not the description. Something we can read, and write to via LSL. a fair number of "memory" scripts could be avoided with just that concession.

It would be awesome if they could fix moving_start and moving_stop (or whatever the events are).. so we didn't have to keep using a timer to see if an object has moved or stopped moving.

Parallel scripts and repeat-calls are the main problems, I agree.
llGetLinkPrimitiveParams() would be top of my list with, as has been said, no artificial delays on any functions. That and let us control a set of prims/faces at once in, eg; llSetLinkPrimitiveParams() or llSetTexture() so one call could change all the things needed. The same ability to address a set of prims with llMessageLinked() would be good although with the other improvements there should be fewer scripts in child-prims, so inter-prim comms becomes less necessary anyway.

Is there a way to measure script performance and resource usage that doesn't require cosying up to a sim owner and having them look at their top scripts tool for you? Something like an ARC for scripts would at least make scripters aware of the environmental damage we are causing.

More controls for parcel owners. For instance radio buttons to disallow all open chat channel 0 listeners, and another to disallow channel 0 unless it is listening only to the owner. That would be better than the current choice of all or none scripts.

Definitely better llListen filters. Add a way to pass lists in a link message, say message and On-rez event. Add structs and struct dictionaries/hashtables to eliminate the need for the slow packing of information into lists with the worse troubles of unpacking them.

Cache results from slow query functions, like radar. Add a function to manage the cache (clear, timeout).

The single biggest HUGE optimization they could make would be to make it so that idle scripts do not take CPU time.

Currently, every running script takes about 2 microseconds of CPU time.

In my experience, this generally uses up well over half the minimum allotted script time on a well-behaved, low-lag sim. This doesn't leave much time for scripts that actually have something to do.

I get the impression that the scripts handler has to visit every script in every object once on each pass, whether or not the script has a pending event.

What would be better would be to have a global queue of scripts (or objects with scripts) that actually have an event to schedule, and only visit those scripts.

No doubt this would involve changes to the way listens are handled. However, it might shed light on how to optimize that as well. But it would be possible to simply always put scripts with active listens on the queue as an intermediate step.

For llGetLinkPrimitiveParams(), I suggest that they implement it except for returning texture keys. That would avoid the worst of script-based copybotting. For most quality products, textures are critial. It wouldn't be a good idea to make them trivial to steal, or give creators a bigger reason to make their products no-mod.

Ditto for sculpt masks, of course.

For lag-inducing calls, I'd rather see policers with ample burst allowances, as opposed to delays.

A policer is something that limits the overall rate of something (per owner, or something like that). We already have some for certain things. A policer has a burst tolerance, so that it polices over the long haul rather than restricting a rate and disallowing bursts. The code for a policer is trivial, though putting a system in place to effect them wouldn't necessarily be.

For LSL, I would probably recommend that when the policed rate is exceeded, the calls silently fail. Of course, the police rates should be documented. (haha, right)

I believe that though delays are easily thwarted by adding scripts (which increases CPU burden), they also send a strong signal that something is considered lag-inducing. That signal is important, and we can't just open the floodgates. I presume this is already in their minds; they're usually not that dense. Of course, policers will break some content -- but that would be content that intentionally works around the delays, and which one might argue deserves to be broken.

Overuse of resources isn't necessarily griefing. There needs to be a way to throttle resource usage. However, delays aren't necessarily the best way.

llSetLinkText()

This would save me numerous small scripts in user interfaces.

llLinkParticleSystem()

Another one that'd save me a bunch of small scripts.

llTraceLine() - SVC-2654
Potentially cuts down on rezzing of huge numbers of temporary prims, enables all kinds of cool stuff, and ends lots of math being done in scripts that's better done (and already done) in the sim. Also drops collisions.

llSetObjectScale() and llGetObjectScale() - SVC-2885
Death to resize scripts! Seriously, we have this functionality in the UI; how hard is it to expose it to scripts?

Babbage already discussed llSetLinkPrimitiveParamsNoDelay() (I like llSetLinkPrimitiveParamsFast() if we must have a new name). I'd rather have a form that lets me call it on arbitrary prims in one call, for synchronized movement.

Uncap non-physical movement; think of the WarpPos code that will be saved.

Remove the flight ceiling. Thanks to Argent and others, it stops no one from going that high; ending the need for flight assists would probably save one script per avatar.

Having avatars behave like normal physical objects (with respect to llPushObject (SVC-1179, SVC-2513) and the rotation functions) seems to me like it'd be easier than the current implementations, but I presume there was some reason I don't understand for breaking them in the first place.

If I could find a JIRA for the animation callback event and better listen filters, I'd certainly vote for those.

For all functions addressing links, I think we could save a lot of script calls if we were able to use a list of target prims rather than only an integer value. That may be beyond the scope of this effort, though.

This is something we need. I recommend "top scripts" for parcel owners.

In addition, "top scripts" should show two values for each script; not just one. Currently, it shows the instantaneous value (the measurement from the last scan). We also need a low-pass filtered value, and the filter time constant should be a variable we can set in the panel. This way, we can see the accumulated CPU usage for each script, rather than simply what it happened to do recently. I detest having to take lots of sample points and mentally average them.

Too slow!! See http://jira.secondlife.com/browse/SVC-835

/me will try to edit the OP with JIRA links if people post 'em..

I will just never agree with this. Enabling a hole because there are already a bunch of other holes just isn't something I can get behind.

/me jumps down off her soap box. I'll shut up about it now.

- More Lindens in the forums!

Seriously. Not to answer all the new-script-people questions we get on a regular basis but, for example, off the top of my head, I thought I read somewhere that mono LSL lists were implemented as an ArrayList - does that mean that llGetListLength is now ubercheap to call? There's also the semi-religious issues of stuff like calling llGetOwner vs keeping a global variable around - is one actually any better than the other?

Wouldn't it be great to have a Linden stop by now-and-then and answer some "how stuff works" questions??

edit: and yeah, I know.. Lindens and the forums.. Like oil and water. Or maybe more like sodium and water.. Either way, this is just a wish list so I can wish for whatever I want!

llGetPrimitiveParams seems to return 000... for most textures already.

You're not "enabling a hole". Whether you drop the scripts in manually, or push them out and set them running manually, it's the same "hole" as llGetLinkPrimitiveParams(). It's a non-issue. Get over it.

What, you switch to decaf or something lately?

It would make copybot scripts easier. It would change them from "takes a few brains" to "any monkey can do it." You wanting the function for other, legit reasons doesn't change that.

/me continues to vote no.

Of course, thanks.