Hiding and showing prims and glow (Part II)

[PeterCanessa Oh]

The loop-constructs offered by LSL, and most other languages in one form or another, are:

• jump x = "go to this place".  Not much used as it's hard to follow.  The basic "go back and do it again" instruction but considered to lead to "spaghetti code" that is impossible to maintain.
• for(){} = "starting like this keeping doing this as long as this condition is true".  The big advantage is that it puts the initialisation, condition and increment in one place.  That's not so much of an advantage if you're messing-around with the loop-variable or condition(s) before or within the loop anyway.
• while(){} = "see if this needs to be done, do it, check again".  With a loop-variable/condition already set-up you may as well just test it, instead of repeating everything in a 'for' or having odd-looking blank parts in it. (for(;TRUE;){ ...} with no initialisation, proper test or increment is perfectly valid).  It's a simpler loop and, if I remember correctly, executes more quickly too (although these things are all relative so you probably won't notice any difference in practice).
• do{ ... }while() = "do this once, then repeat as long as required".  A convenient variation of while().  It's not necessarily 'better' but there are some times when you want something done at least once.  This is the neatest way to do it.

Gemerally, yes, a shorter script is faster simply because it does less.  It also takes less of the available memory for the code itself so can use more for data/processing.  Using fewer variables also means it needs less memory.  Thirdly, you're likely to make a shorter script work sooner because there's fewer places to make a mistake!  Conversely, being TOO clever makes the script hard(er) to read and so harder to maintain.  It's all a trade-off.

[Void Singer]

another important distinction for loops is the order they do things in

for:
test
run code
modify test variable
repeat

do:
run code
test

while:
test
run code
repeat

generally with the latter two the modification of the variable is done IN the test, or in the code,  by default, and in for loops, it's done after the test and the code, which can make a difference in your counting logic. all three can be rewritten to mimic the others, by changing where the modification happens or adding wrapper code, but they'll be less efficient.

do is technically the fastest loop type, but it's limited to cases where you know that you're going to have at least one valid test (the first one)

while is the second fastest, only by merit of it being one test longer than do, assuming there are any valid tests (otherwise it's faster than do, because it doesn't run useles code)

for is the slowest of the three, probably because of the extra declarations, but it is useful if you need to modify your test variable after the test AND code. it's also convenient (although more for languages that let you initialize the variable in the call)

jump USED to be faster than all of them, but now seems to be in about third place generally, it requires an if test to be used as an exitable loop, although if you just jump with no test or exit clause, then the inffinite loop is faster than all the others....

 

there are also event loops, and event chain loops... the most notable one is calling a state change from state exit, which is blindingly fast for some reason. the same trick works for modifying a prim property from the changed event, or sending a link message to the local prim from the link message event, etc..... dataserver is the most common event to use this way, with notecard readers being the most obvious example.

event chain loops are where one event triggers another one, in a daisy chain fashion, with the last in the chain triggering the first. they aren't very common, and the simplest example I can think of is an online indicator, where the timer event triggers the dataserver checking online status, and the dataserver changes the timer... although that's not a GOOD example.

 

loops triggered outside of the script by interactions with the world or other scripts are considered to be "moderated" by their communications method, and are termed feedback loops (because they rely on external feedback)

 

@Scion specifically:
smaller is a quick indicator of speed, but not an absolute one. all the replacements I made are faster equivalents, based on knowledge, experience and testing, the suggestions on the other hand are based on knowledge of dealing with "unexpected" cases, some of which are actually expected if you are familiar with programming (because of knowledge of the basic action that can occur, but aren't always considered) and some are a result of unique "features" (mostly bugs and limits) of LSL, that have to be learned along the way (although we try to document them in the wiki.

[Sion Pearl]

I'll be honest, I didn't understand most of that, but I did ask and you did answer. :robothappy: Got a lot to learn.

Anyway, the new script works fine too. I haven't had enough time to see if it's faster or more reliable, but it's certainly working. Thanks again.

[PeterCanessa Oh]

About scripting/programming in general:

• Making the &*^%*^ thing work is most important
• So first learn how to do it
• There is always another way to do it, which is part of the fun
• So (try to) learn other ways to do it
• Making things easy-to-read/maintain and efficient/fast is usually a trade-off, there often isn't one "best" way
• Writing something that you can understand (so fix as required) is initially more important than making it 'good'
• But obviously we all want to be proud of whatever we create so 'as good as possible' is the ultimate aim

Beyond that we get into questions of style, naming-conventions, layout, etc, which usually come down to personal preference and what you're used to.  Knowing different approaches and techniques gives you more options, but it isn't worth confusing yourself with and no-one's working solution is necessarily 'best', just 'better' in certain aspects (some might just be all-around 'better'.than others but it's comparatively rare that a really, really, bad script/program will actually work).

Void is particularly good at making things efficient although, for me, less readable so she might disagree with this but my recommended priorities for anything are:

1. Make it work
2. Make it clear
3. Make it efficient

And specifically by 'clear' I mean tidying - get rid of unnecessary variables, event-handlers, etc. add consistent comments, indentation, variable-names, etc.  By 'efficient' I mean optimisation - through experience use all the tricks you can to make it smaller and faster.

[Void Singer]

 

---

PeterCanessa Oh wrote:

Void is particularly good at making things efficient although, for me, less readable so she might disagree with this but my recommended priorities for anything are:

1. Make it work
2. Make it clear
3. Make it efficient

---

actually no, I wholeheartedly agree with that, and only know of one exception to that list offhand.... and that's if it won't work unless it's efficient... and that really isn't much of an exception (it just combines 1 and 3)

 

optimization is a funny thing, in that there are lots of things you can optimize for, and rarely do any of them go together.... speed, size, portability, readability, reusability... and chasing one often means ignoring another.

my posts for this thread aren't aimed at OP really, but rather anyone reading.... the hopeful idea is to demo some structures and considerations that might be new to the reader, and get them more familiar and comfortable with them and how they work...

 

[PeterCanessa Oh]

---

Void Singer wrote:

 

my posts for this thread aren't aimed at OP really, but rather anyone reading.... the hopeful idea is to demo some structures and considerations that might be new to the reader, and get them more familiar and comfortable with them and how they work...

 

---

Ditto :-)  Talking 'about' most of the time, hoping it helps someone.  Entirely agree about optimisation too.  Hehe, as you know, I prefer 'elegance' in my code anyway, which is possibly another form of optimisation :-)