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

It doesn't make them significantly easier. Seriously. The amount of work needed to copy parameters even if you do it the slow way, one parameter at a time, is an order of magnitude more complex than the small amount of extra code needed to push a helper script to all the prims and then manually set them running. There are sample scripts widely available for "prim cleaning" that do that bit. ANYONE who can write a successful copying script already has the brains to work around the missing llGetLinkPrimitiveParameters. The "any monkey can do it" solution is copybot.

Yes, and adding llGetLinkPrimParams will make it so that people with less scripting skills can whip up a script fairly easily and not have to bother with copybot. (aside from textures/sculpts).

LL left out llGetLinkPrimParams for a reason.

No it won't. With or without llGetLinkPrimitiveParams it's NOT a trivial script. Working around that lack doesn't make it significantly more complex. The missing code is publicly available.

If they were always right Babbage wouldn't be asking how to improve things.

/me does not agree. Seems pretty trivial to me.

I'm not interested in arguing any more. Not even a little.

If it's trivial, then we need a new word for the workaround for missing llGetLinkPrimitiveParams.

The potential uses for this function greatly outweigh the imagined potential for abuse (which is actually very slim), the comments for the relevant JIRA cover this quite exhaustively

Most things are already mentioned here; I do quite like the idea of advanced event filters, especially as mentioned for listens, as the cost of creating, queuing, and even firing events can be fairly high, especially if they do nothing more then test a value and return most of the time, any way to cut out extraneous events is a good thing, but needs careful testing to be sure it won't add bloat rather than reduce it.

The main thing would be in trimming as much bloat from the Mono start-up process as possible, or at least restrict the impact of heavy scripted objects to the avatars who are actually wearing them.

/me does not mean to bitch at you but, ya know, it's not like I don't understand that people are saying this. I can see how to write a copybot script quite easily with the function and think it would be a fair amount harder (but still doable) without it. All I'm sayin' here is that I don't support things that make content theft easier.


Absolutely. I figure anything they do that prevents scripts from being called (when they don't need to be called) is goodness.


I think Babbage already knows about that one.

That's not really stuff that we, scripters, have any control over - there's not a lot we can do to make it better or worse. What I was hoping for more of was ideas that would allow scripters to do things in ways that are less costly to the sim..

This isn't a matter of "I can see how to... and I think". I've written equivalent scripts, and the amount of extra work to copy a helper script to the child prims is a LOT less work than getting the parameters lists serialized properly (no, you can't just use llList2CSV, and some parameters have different numbers of arguments depending on the prim type), deserializing the lists (and fixing all the type issues) and even just writing the base listener code.

I've also built parameter serializers and agree with Argent. It's not trivial at all if you want to really make it work.

I thought you were a hedgehog, not an ostrich j/k

Seriously though, we have libsl, Copy Bot, ThugLyfe, NeilLife and a crap load of other viewers now. With the majority of those, all you have to do is click a button with NO scripting at all involved. Depriving the majority out of fear that the minority will find it easier to steal, when they do not need to even know how to write "Hello World" to steal is indefensible. LL's previous stance of not supporting llGetLinkPrimitiveParams was ludicrous. This is like proclaiming to the world that your house is secure because you have an expensive dead bolt on the front door but just a screen door in the back and no window panes in the windows.

/me wishes this thread would get back on track...


< font size=ginormous></font>

there are some slight workarrounds for this, we can currently get memory size and speed of execution of script segments, but they've been promising something like top scripts for a long time, and it is really useful, and we need it...


download a copy bot (which will do alot more than simply copy prims), or write a whole script to copy parameters and duplicate them elswhere... and still not be able to get complete info on various torture hacks....

and this script can already be written (i know because I wrote a version)... at most it now requires a few extra steps, which are all well documented in this forum and the Portal. meanwhile the lack of the functions only introduce multiple sub script overhead which would be a major cause of lag..... not to mention having to store that information locally to track it for the lack of the get in normal applications.

so I respectfully disagree on the dangers (and the difficulty is only slightly reduced, since there are still several caveats in the differences between the set and get formats, and multiple faces, which are more complex than the simple messaging that it would obviate)

(but I'm still amazed that rezzed objects script insertion causes such a huge spike compared to border crossing script insertion. something there isn't right at all)

Just to add to Void's post -
We are promised more and better tools for script-analysis before they introduce the proposed limits. For anyone that doesn't know about those ... there are proposals to limit scripts. Er, that's about it at the moment, lol. The limits will probably be memory-based, per-parcel and per-avatar but that's just 'current thinking' and nothing is set in stone. We were going to be getting the tools 'towards the end of the year' with the limits being introduced 'early next year' but it's all slipped back by at least a quarter, by the look of things.

Anyone got any new news on Babbage's progress with limits and the tools to cope with them?

For the latest on limits and other memory things see http://wiki.secondlife.com/wiki/User:Babbage_Linden/Office_Hours/2009_11_25?

The tl;dr version:

Freezing is not a normal consequence of the validation step after all, it's an actual bug. Babbage is digging into why it is happening, the Mono version hasn't changed and this bug wasn't being triggered in the past.

The numbers are basically in for how many sims are using too much memory, about 5% of them.

Some sims are being linked with google perf tools now, the hope is that this will reveal some causes of memory bloat that show up in production but not in test copies of the same regions.

(Nothing new about measurement tools for us, those are blocked on the vaporware formerly known as Viewer 2009.)

/me requotes the OP in hopes of getting more suggestions. Or is this really all we have?

heyas;

what would be useful on listen filters, to me... is to be able to do partial string matches. and case-insensitive matches (non-case-sensitive?)

like, if i want an object to activate on hearing the word 'wham' i would need basically 3 listeners on it:

one for 'wham'
one for 'Wham'
one for 'WHAM'

then anyone who said Wham!!!! or WHAMMO! or whatever variant, would never be able to trigger it, anyway.

so right now the only solution is to listen for everything and then in the listen event, find substring blah blah 2 lower 'wham.'

this is just a quick example, i would never write an object that listens on open chat for a trigger word. but i have done one that listens on channel 1, and really, its still the same overscripting to find one word in the command it receives. just on a slightly less chatty channel.


i vote for script time tools for parcel owners! zomg, i NEEEEEEEEEEEEED it! and for a real get memory that works right and is accurate and btw... a FREE MEMORY function that frees up memory would be nice!
i have a script set now that is storing a big list of numbers -- but they are only numbers, not strings. i have other variables passing long strings back and forth, but only temporarily in re-used variables. and when i get through doing a lot of those, WHAM out of memory, script dead, toast. i hate that. ::sigh::


memory management.

lag analysis tools. you want less laggy scripts? give us tools to see just how laggy they ARE! we can experiment with different methods and find out. really, 'low lag' is a big selling point for scripts and most scriptors with any sense want to make their code as lean as possible.

Here's a few things that I miss from other virtual worlds, translated to SL terms.

1. llTeleportAgent(key avatar, string sim, vector off, rotation rot).

Get rid of 300 different WarpPos/PosJump/SitOffset hacks.

2. llDetectAttachments(key avatar).

3. llMemberOfLandGroup(key avatar).

For avatars in the current sim. So you don't have to play the damn title matching game. Land group, not object group, because the sim knows if the avatar's a member of the land group already because it tracks that stuff even if it has to do a database query for non-land group membership.

4. list llRegex(string regexp, string target).

5. llGet/Set[Object/User]Attribute().

Not just the inter-object database access I suggested in my first message, but give users this ability as well. Let people add "Gender: male/female/..." to their account, IF THEY WANT... along with all the other possibilities (species: ferret, clan: campbell, soup: cream-of-onion, tribe: eastern standard, race: vulcan, rank: ensign, scent: rank , ...).

6. Anchored prefix listen matches would not add any more overhead to listen than the current exact matches, and would massively reduce the number of listen-to-everything matches people have to use.

I've been scripting in SL for years and reporting problems in Jira as long as it's existed and many other scripters have reported far more than I. But guess what? They just sit there for YEARS!

The problem is not a lack of ideas and suggestions, the problem is they are completely ignored.

/me listens for the choir to shout "Amen!"

Yes. I know I've added JIRAs before that seem to get totally ignored. And I've seen LL close ones as "won't finish" then, months later, they do it anyway.

Don't get me (or others) started on how long we've been screaming about SVC-4196/SVC-3895 in the blogs and gotten virtually zero response from LL - there was one "Babbage is looking at it" recently but that's it. That's the grand total, right there. After months of asking and asking about it. And using JIRA, which is what they tell us to do. This bug has almost totally destroyed SL for me and unless you dig through Babbages office hour transcripts, it seems like LL couldn't care less about it and (almost) refuses to even acknowledge that it exists.

Yes. There's much work that could be done on resident/LL communications. You are not at all alone in being annoyed.

That said, if you got ideas or pointers to relavent JIRAs, posting them here would be nice.

edit: and can we pleeeeeeeeaaaaase not let this thread devolve into an LL-bashing fest? Please?

Excellent suggestions, especially #6. llListenPrefix()? (same as llListen, but the message string is a prefix to match rather than a full string)

However, if they implemented listen correctly, it's not feasible -- or rather, it would be expensive. They should be using hashes. Somehow, though, I suspect they're not.

strictly lag inducing, mostly from this thread, in no particular order.

1. include relevant get/sets for all prim parameters that can be modified, at both prim and object local levels. (removes memory and multiple script tracking needs)

2. teleport would be awesome (remove all the movements hack arounds)

3. some type of small static storage, the world is persistent, data should be too. (remove the need for web communication in light data cases)

4. look into the rez/insertion problem for mono (reduces rez spiking that shouldn't be happening anyway)

5. remove forced delays from function calls, and use per object, or per user on region caps for communications. (removes the need to multiparse, and prevents gaming the system by doing so)

6. RegEx (remove the need for complicated filters and data shaping logic)

7. llName2Key (and remove all the need for web coms processing on key lookups)

8. script monitoring tools (if we can't see it, we can't fix it)

9. Animation ending callbacks (or viewer incorporated AO's) (removes tons of polling, coding, and is possibly the one true necessity in SL)

10. lift (not remove) flight ceiling... preserve a rezzable zone above it for privacy, but allow more range of flight. (reduce the need for scripted transport any kind to those heights)

11. documentation on limits (if we know them, we can prevent them from kicking in and potentially losing data, or making pointless calls that just chew up cpu time while silently failing)

12. implement better sorting on lists(bubble sort... really? come ON!) (speed up processing)

13. includes (potentially decreases code size with shared functions, and lack of extra coms, but that's up to implementation)

Good summary, Void.

For #8 (tools to see script usage), it might also be good (for us, for LL, and for everyone) if in addition to the column for CPU time, include a "lag" column. This value would be incremented whenever a script did something hoggy. For example, sending email might incur a penalty of 5; sending in IM might be 1, based on some analysis of the typical relative costs. Just an idea. Like ARC, it would be an estimate and sometimes misleading, but it would be a way for those who didn't write a script and can't read it to evaluate how much a script contributes to overall problems. Folks might get a clue that scripts that check whether a worker is ingame should check every 5 minutes rather than every second! Currently the buyer/user has no visibillity on this.

(A friend of mine scripted a "worker online" sign. It checked every second. A relatively new scripter, she asked me to review. I suggested she change it to 5 minutes, and make that clear in the documentation that this was a benefit for LOW LAG. Her signs turned out to be rather popular, she made a nice pot of cash from it, and I'm very glad I did. But many product scripters don't like to make any tradeoff that makes their product appear less than perfect in any way, even at the expense of lag, since the source is hard to pinpoint.)

For #9, use "notification" rather than "callbacks". I assume they'd introduce a new event, either of a new kind (new handler) or else something that fits into an existing handler (e.g., dataserver, listen).

For AO use, wouldn't we really want avatar state change notice, rather than animation end?

#12: bubble sort? REALLY? They couldn't call quicksort or heapsort from the interpreter context? Eep!

#13: includes wouldn't affect code size. That would require a library, which I suspect would add quite a bit of complexity. Even includes wouldn't be simple, if I understand things correctly. What would the include line specify, a full path name in your inventory? What happens when the script is recompiled from someone else's inventory?

I don't see this one as a likely possibility.

If they don't eliminate the flight ceiling completely people will still be using flight scripts, so there's really no savings from just increasing it.

I think this is a terminology issue. There are technical differences between callbacks and message-based event handlers, but they're subtle and in this context I'm sure an event was what was intended.

There's a tradeoff. If you try to index on everything, you increase the cost of insertion, and you start having lag caused by adding and removing too many listens. Based on comments by Lindens, they have separate queues for channels but then after that they do explicit tests on each event, and I think even check on things like distance and key before they do the relatively expensive string comparisons. So if they were to use hashes they'd have to have a LOT of hashes, most of which would only have one entry.

Doesn't mean it wouldn't hurt to have a hash on channel zero, but I don't think it'd be an automatic win. You'd need to do tests.