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

Yup, just semantics, but it's such a good list, it would be best to use the right terminology to avoid confusion.

Thus my suggesion for "notification", which doesn't imply any particular implementation.

Agreed, and very good suggestion about possibly treating channel zero specially.

I wonder how much instrumentation is built into the SL servers and in particular how much lag good instrumentation would introduce. I've often wound up building systems which can have their instrumentation turned off for the prod version to avoid performance issues and wonder if LL has similar versions.

If so, how about having several test sims that are only used for testing and which are heavily instrumented and configurable. Perhaps there'd need to be a signup scheme or something so people could use them in a controlled environment.

true, but if the height is increased drastically (say 204 it removes the need for most uses, still prevents idiot newbies from flying up to 1mil+ meters and "getting lost", and still provides a zone which is buildable but not flyable, for simple privacy. it also allows flying in the at non mapping heights so people can have their skybox in range and still not mapped it won't absolutely limit use of flight assist, but make it's need so rare that most people wont bother.

as for the AO, yeah, a "animation state" change event notification, that triggers on each new state start, but it really is best envisioned as a viewer side thing since that's the most likely stimulus response, the shortest path to change, and least impact to the grid. the problem is that it requires a different model of distribution, and scripting... although that could be a good thing, it might also be a security hole.

People will still wear them, starting with the first time they fall out of a skybox at 3000 meters. Because apart from flying to a skybox or "safety" when you're in one, there's no reason to wear one right now.

sure there is.... avoiding ground clutter and extra rezzing mess =)

ok, couple of thoughts I've had in the back of my head for a while

lLinkParticleSystem(integer linknumber, list rules)

Works EXACTLY like the particle system does now, but the particles come from the prim specified by linknumber.

If you do any work with lighting effects, maybe fountains and the such, or the Lockmeister system... you have to have the script in every prim you want an effect from. I could eliminate a minimum of 6, in some cases 15-18 scripts out of some of my builds.

llEventIgnore( integer eventtype) (could use a better name)

llEventIgnore(LINK_MESSAGE) // this script doesn't have a link_message handler, don't wake me up to handle something I can't

llEventIgnore(COLLSION)

llEventIgnore(LISTEN)

llEventIgnore(TOUCH)

etc.. etc.. etc...

/me likes the llLinkParticleSystem idea.


I think LSL already does this internally.. I could be wrong, though.

If you don't have a link message handler, it shouldn't be waking you up anyway. That should be fixed in the event system if it is.

I believe I read somewhere that the scripts got 'woke up' if there is a collision or listen or link message even if it didn't have a handler (specifically remember it on collisions).. I could be wrong, but might be worth looking into.

Would being able to have lists of list be of any value?

That way, something like the suggested

lLinkParticleSystem(integer linknumber, list rules )

could be

lLinkParticleSystem( list linknumbers, list ruleslists )

which would allow you change the particle systems in multiple linked prims with distinct rule lists using one function call.

If lists of lists is not a good idea, then maybe

lLinkParticleSystem(integer linknumber, list rules )

could be

lLinkParticleSystems(list linknumbers, list stridedrules )

which would also allow changing multiple linked prim's particle systems with one call.

Or less useful but still maybe worthwhile

lLinkParticleSystems(list linknumbers, list rules )

which would apply the same one rule list to multiple linked prims with one call.

If they do, that can be fixed without adding an LSL call to tell the event handler something it already knows.

You would think...but I have a feeling that .. well how shall I put this delicately... the LSL compiler is too stupid to bother to note that when it compiles the code (oh this one dosen't have a Listen, a Collision_* a Touch_* a Link_Message handler... ) so the event handler may well NOT know... but then Baggage could tell us better (and I'll go back in my little corner and play with my particles )

Not true. Events being handled change on state entry. Watch what happens to the touch in the pie menu as you switch between states with and without touch events.

Ah.. ok, touch, yeah... but I'm unsure about the rest. Worth discussion I guess

I don't see how it would be possible to make the event handler *work* if it didn't know the events handled on each state. Nor can I see what it would mean to "wake up" the script if there was no code to run.

A script gets visited EVERY pass, even if it's in a state with no handlers, or just a state_entry handler. THAT's what really needs to be fixed, to reduce the cost of dormant scripts.

Most sims are chock full of dormant scripts.

When SVC 1853 was being discussed a year ago it was also noted that starting and stopping scripts was laggy so even if it were safe to make unused scripts inactive, apparently the start / stop operation itself is a problem.

It still seems to me that the lowest hanging fruit is to just fix this so scripters can shut off scripts that aren't being used.

A related idea might be to have a third script state for things like sunset/sunrise operations, resizing, setups, etc. that don't have to respond instantly. Rather than constantly revisiting these on each cycle, they could be checked say every forth cycle.

If "visiting a script" requires more than performing a single array lookup to see if an event is relevant, that's a bug that needs to be fixed, not worked around.

If it doesn't require more than an array lookup to see if an event is relevant, then the fact that it's visited is irrelevant and no action should be taken.

Interesting idea but am not sure it'd work.. The problem is that it'd get sticky if the rule set for each link particle system didn't have the same number of things in it. Like, if one needed to do a color change and another didn't, their rules would be different lengths. Tricky for the sim to figure out where one ends and another starts...

You could say that each rule set needs to be the same length, I guess. Not sure that there's a performance win on that, though - guess it depends on how costly it is to make multiple calls, one per link, vs being able to do multiple links on one call.

I really like the llLinkParticleSystem idea. Is there a JIRA for that yet?

Not that I'm aware of.. yet.

not dormant... idle, dormant scripts are ignored.... but argent is right, their check needs some help (there has to be some kind of a check to see if any conditions have triggered events, and also the script time counter is also always running as long as the script is running, and probably used as the convenient check point.

I haven't measured it recently, but in the past just having a few thousand active scripts even if they were just waiting on events (timer or touch typically) would severely lag a sim. If that's not true anymore, that is if just having a bunch of active scripts that aren't running isn't an issue, then a lot of this discussion and the plan to limit the number of scripts on a parcel doesn't make sense.

/me, who owns a club, usually sees 7-8000 active scripts at her home, measured via ctrl-shift-1, at her home. though I've seen it spike up to +12k. There seems to be a line around 9-10k where the sim really starts to thrash. If it's over 10k, that's sorta it - lag central...

So, nowdays, "a few thousand" scripts on the sim isn't *that* painful (though I'm sure it makes Babbage cringe) on an otherwise empty region.

1. A few thousand LSL scripts hasn't been a major cause of sim lag since they brought in script throttling, at least a year or two ago. A few thousand mono scripts, if they're large, yes... because of the amount of memory they can take up.

2. They're not limiting the number of scripts, they're limiting the amount of memory used by scripts. The issue is memory use, not scheduling or event handling.