Keeping my script low-lagged.

Lately I have been active with some new scripts, and while I am programming in RL, LSL works in mysterious ways

Now I have a couple of questions regarding lag, and total script time.

llMessageLinked
==========
This one I use to have scripts interact within the same prim, but also to tell scripts in other prims of the same link set, to perform an action. How much does this contribute to lag, especially with the LINK_SET parameter?

Dataserver
=======
Most of the information needed is read from notecards, at first rezzing, or at Reset (menu option). Though this will create a peek at the time it is ran, I suppose this is harmless after the run.

llListen
====
This one I use during notecard reading, and during interaction with a user that clicks the item. Maximum runtime is 30 seconds, after that it closes.

Now my main issue is, what do these things do when no one is interaction with the object they are in? Imagine this:

A couch has the main scripts in a rootprim, and a child script in each of its 5 parts. The child scripts only have a link_message state, and are used to change the color or texture of the couch.
50 of these couches are in my store. At rezzing time the scripts are ran, after that they quietly wait for customers to try them out.

What are the thoughts of you experienced scripters about this? Do the couches use any resources when not in use? Is link_message to be compared with an active listener?

Thanks a lot, Marcel

I'm no expert in this area, but link messages are the way to go when communicating between prims in a link set. It's my understanding that it's very low lag. The data server event is probably a bit laggy, but like you stated, it's done initially, and then it's done, so there's no lag at all after it's completed. Listen events can be laggy, but you're right to close it when not in use, and, if possible, you can filter your listen to only process chat from the intended receiver. However, since you're closing your listen when you're done, it's not a huge deal. As a newer scripter, you seem to have a good handle on it. If you have (or know someone who has) estate privs, you can check your scripts to see how much lag they're generating as well.

llMessageLinked is a difficult way of communication but I got it covered I guess. It seems that LINK_SET can cause more lag then LINK_THIS, so I will make sure I got that one covered. Of course that part of the lag is only there during the messages, at first rezz or at reset.

My main question is that if I have 100 items with a scripts in them that are doing nothing (as long as not clicked), do the link_message() events count towards script use. Hard to explain when not native speaking Having 100 open listeners would be very bad, but how must I see link_message() events?

although those numbers were generate pre-MONO
more info @ http://wiki.secondlife.com/wiki/LSL_Script_Efficiency

I know the that communications using LINK_SET & LINK_ALL_OTHERS use more process time than than the more targeted one, I don't know by how much. at one point those two were also slightly flaky for large linksets (intemittant random recieve failures), I don't think that's still the case.

script memory on the server may behave a little differently in mono, as it seems to favor the current state (Strife posited some type of JIT compilation for the active state) you may be able to reduce the impact of some non-op event handlers to different states (like a separate state with a dataserver event for your notecard reading), but really I'm just speculating there.

any inactive event probably isn't going to have much more impact than any other inactive event, other than maybe server side memory-wise as I speculate above. obviously it'll be noted in the reference table, taking up a hair of space but I'd think that's relatively minor. and actually, since both dataserver and listen are handle based events, they may take less since they have no references when inactive.

on a related note, (and I know some people hate this topic), micro optimizations like --variable instead of variable-=1 or variable=variable-1 can not only speed up code in loops and shave fractions of memory, but also enable more total scripts to run faster in the shared sim environment. arguments against usually tend towards unreadability, and proper algorithm optimization, but it can't be denied that if applied across the board by everyone, it'd improve the general environment for all.

Great link Void, I never knew that there was such a difference in how you add (++a versus a++).

What I also read is that the number of inactive scripts add to the total script time usage, but it is not always possible to avoid that. Like when I put a color/texture changer in a couch, not all elements should change. Now I could work with link numbers, but that is asking for problems. My stuff is modify, so as soon as people change the linkset, the script stops working. Luckily my stuff is low prim so it is never that many scripts

there are a few ways to cut back on those extra running scripts, one would obviously be to use set link like you were thinking, and there is a way to target a specific prim without relying on the number... get a list of link names to coincide with the link numbers, then target the index of the correctly named part. this should work for colors, probably not so well with sizes in a +mod item.

you can have the individual prim scripts set a pin number, and after doing their work, turn off. then when you need them again, push activated copies from your main prim, and have them do the same thing, set a pin, do their thing, then die.

you may need a bunch of pusher subscripts, since remote load has a three second delay, but if they are in the same prim as the server script you can wake them with set other script state, let them push out new active copies, then turn themselves off again with set script state.... result, one active script while the modifying functions are not being used. this method isn't going to help if thoses modify functions are likely to be called frequently though. oh and definately encode and store that script pin someplace safe, like the description, or hard code it, so that a bad sim crash doesn't break your ability to pull this trick.

Why use a script in each prim to change texture/colors?

A single script in the root prim can do that no matter if people delink and relink the objects or add new objects.

And if you only want to change cushions for example, then name the prims; back, cushion_1, cushion_2, arm_l etc. Build a list with the link names and use that.

That whats our N&B Furniture does

Whenever I am using LinkedMessage I use a what I call a "register" system where the root prim sends a message to all its children asking for them to register their link numbers ( or I call them Link IDs ). This is like using the name system mentioned above.

An example would be of a board game ( although this requires the prims in the link set to be linked in a consequtive way ):

Root prim sends "REGISTER" message to all children.

The top left prim of the "board" sends a message "REGISTER_CONTROL_PRIM"

Then the root prim grabs the message uses a for loop i.e for( i = sender; i < numCells; i ++ ) then add the link numbers to a list or string.

Using this mehtod either in a pre determined way of linking or a random way of linking makes it easier for me to script certian parts of the object / game or whatever. Plus you don't have to mess around with names and if a user has modify permissions they could change the name and then it could get messy. That's they way I like to do it. Other people will have their own way, my advice would be script in the way you feel comfortable and make sure you understand what you are doing.

I feel so unread....

Oh you posted something?
I snuck in my post at work and didn't get a chance to read all, including where you already said build a list of link names

Well thanks a lot people!
The idea of named prims is a very good one and I will use that in my next try. So I guess I use llGetLnkname() with a loop over all child prims to check if they are meant to change? In that case I would not need to give them separate names either, just name them all "x" would do as well I guess?

Furthermore I split up my script in a few parts, but now I read that less scripts is less script time somehow, so I might turn that back. What I do now:

1 script to read notecards and llMessageLink() the values to the other 2 scripts (only at first rez or reset).
1 script reacting to touch()
1 script reacting to changed()

Was better readable, but it seems that combining them back into one script is more effective regarding scripting time.

lol it's no biggie, it happens.... I just occasionally feel silly and have to note it... (I'm sometime guilty of the same)