Optimizing X num scripts for simultaneous actions?

I have a little project I'm working on, in which a variable number of child prims must act at the same time.

as an example

user selects a number in the range of 1-10 (say user selects 5)

root prim script loops through that number, setting flags for activation in child prims of that number (5 in this example)

later, upon activating, root prim script sends LLMessageLinked to all children, and the active ones fire.

but there's 5 scripts sitting there doing nothing except disregarding messages.

seems like a waste.

note: due to delay times on certain calls, I can't run them in sequence, it borks the effect.

anything I can do to fix this?

PS I realize # of scripts impacts lag overhead, but does size also? or only the actions occuring?

The script is always 16kb. In that 16kb is the bytecode, the stack and the heap. The stack starts immediately after the bytecode and the heap grows backwards from the end of the memory space. In this light a stack-heap collision is exactly what it sounds like. Size of a script has no bearing upon the impact it will have, except that the more bytecode that is actually executed the more the impact.

Yes it's a waste to have multiple scripts just sitting around ignoring messages but there really is no other option unless you can combine scripts. One thing thats going to have a big effect is the number of scripts that simultaneously parse a link message, you do not want 200 scripts parsing a message at the same time, the sim _will_ take a performance hit. Avoid LINK_SET, LINK_ALL_OTHERS and LINK_CHILDREN at all costs.

I wrote (before llSetLinkPrimitiveParams) a windowing API that allocated and deallocated prims dynamically. To avoid using the LINK_* flags and having each script listen for its individual updates, I wrote an abstraction layer that handled the allocation and proxied the messages to the correct links. Sure it meant the messages moved slower but it didn't drag the sim down on every single update. TLWAPI is one of my best scripts, it's reasonably fast and it's tight; only problem was it became a bottle neck for messages, I have always wanted to run multiple synced copies of it. Never figured out quite how.

I considered something to the effect of moving all the scripts from the child prims into the root and using llSetScriptState to turn on/off the used/unused scripts, but it makes a big bloody mess of the root, not to mention requiring indiviual customization of each script to target it's original child prim.... I suppose I COULD do that, and move them all to an unrelated "server" prim.... I'm looking at ~20 scripts

I'll take a look at TWLAPI, thanks

If you have a non visible face available on the chip prims you could try using llSetLinkAlpha. Then you test in the children:

changed(integer change){
if(change && CHANGED_COLOR){
if(llGetAlpha(0) == 0.0){
//do something
}
else{
//etc
}
}
}
 
[\PHP]
 
This is one of the communication options I use in my HUDs, been awhile since I test but I seem to remember it being fast.

Now that raises an interesting question: I think the amount of processing used by an idle script is pretty negligible (though certainly non-zero), but what's the trade-off between sending link_messages to *targeted* child prims, vs sending a "keyed" message to all the scripts in the same prim? With the "same prim" approach, each contained script running in a state with a link_message handler will have to process the event just enough to compare the integer argument for relevance. (That comparison itself isn't the concern--probably comparable to the cost that would be incurred in figuring out which prim to target--but "waking up" the scripts to process the event and make the comparison might be a hit.) With the "targeted child" approach, only the relevant scripts get events to process--but does anyone know if there's inherently extra overhead in sending a link_message to another linked prim, compared to sending it to LINK_THIS?

Well I haven't packaged a public release of LTWAPI before but here we go...

http://mailerdaemon.home.comcast.net/TLWAPI.zip
http://mailerdaemon.home.comcast.net/CombinedLibrary.zip

You will need the second if you want to compile the ESL to LSL.

ESL is just LSL passed through a C Preprocessor and then stripped of extra whitespace.

@Strife:
thanks, I was thinking you might have ALREADY left it out wild somewhere ....oops

@Jesse:
there are "some" communications that this might work for, once the children have been configured.... t/y hand't actually tried that avenue.

offhand does anyone know the total # of faces on various prims, including cuts/hollow? can't seem to find that... maybe I'll test and post back.
EDIT: n/m found it on the orig wiki, it's 8

@Qie:
the (in)activation of scripts shouldn't come often, and would only occur on config in this case..... theoretically they might never be used again (which is kinda why I'd like to kill them). I think I'll check on putting them all into a "server" child prim, targeted from root. I did already go the keyed aproach. I learned the hard way from having a random user script dropped in my object what havoc that can play otherwise. must test that if I can. thanks i'll post back.

@"all"
thanks for all the ideas =)

EDIT: I really wish LL would get around to fixing the boards, the links would be nice again, but reading some posts (not this one) w/ the formatting exposed is a headache.

You can find face count information here: https://wiki.secondlife.com/wiki/Category:LSL_Face

if you do use TLWAPI, you will need to retask the message format for the addressing system.

I wrote this GreaseMonkey script to make stuff work on the forums like it use to.
http://userscripts.org/scripts/show/9651

OMG this is sooooooo cool. You can use Strife's BBCode script in Opera. Copy the script to notepad and save it with whatever name but you must put this on the end ".user.js" so that you will end up with something like BBCode.user.js. Then just follow the directions on the page under "How to add scripts".

http://operawiki.info/UserJS

You do not need to do the extra step of editing the .ini file.

I see Suezanne had already posted the Opera workaround in the Resident's Answers BBCode stickie. I went ahead and posted the instructions to Torley's JIRA post.