code optimization trick?

I saw a trick the other day but I can't seem to remember (or find) it..

something to the effect of
if (~llListFindList( [test], some_list)){

obviously that's not quite it, the point was to catch a -1 return value and treat it false, while using something that's more effcient than
if (llListFindList( [test], some_list) != -1){

anyone know what I'm talking about?

and is this really any better than the second example?
if (llListFindList( [test], some_list) + 1){

::is clueless how to see difference in bytecode compilation of LSL::

You were correct it is using the bitwise '~' operator.

You see -1 is all the bits turned on (0xFFFFFFFF) and if you use the not operator on it, it flips all the bits, so -1 becomes zero. It's faster then != 1 or +1 and uses less bytecode.

Also for single list entries you will find the (list) typecast uses less bytecode then wrapping the value in brackets [].

/me smacks self in head

for some reason I had ones compliment stuck in my head for the representation of -1, instead of two's (1110 vs 1111)

and thanks for the typecast list trick, hadn't seen that one before =)

Holy crap, list typecast! Great stuff.

=P
I meant as an optimization

Note that this kind of peep-hole optimization is generally best when limited to cases where it matters, i.e., inside tight loops or handlers for frequent events, or when it's crucial to minimize the amount of code space.

Thanks for the tip about the (list) cast being more efficient than a list constructor! There's no reason not to use it since readability doesn't suffer.

Agreed, but here's a question:

How about (result >= 0) instead of (~result)? It's certainly more readable. If there's a comparison to zero operator in the virtual machine, it ought be smaller and faster. If not, then I'd guess it's the same as (result != -1), and not worth it.

s'often said, if you're running butt-cold into stack heap/mem probs, make a copy of the script and optimize the heck outta it and keep the original as your working reference. as you learn the new tricks, you'll incorporate the optimazations more on-the-fly in your pipeline.

now you say that (list)"typecast" is more efficiant than ["bracketing"] for single items - so that is a certain 'not so' for multiple items? (which should use bracketing?)

Byte codes (virtual machine languages) usually wouldn't have such an optimization -- they're intended to be simple, not optimal. For code compiled to run native on a machine, this would be ideal because it's clear and it avoids loading a constant. But, that's not the case here, as you suspected.

For multiple items, you have no choice: you have to use brackets. If you tried it, you'd see.

OMG we have ANOTHER readability argument.

LMAO. Do a search here in the sripting forums on "optimizing" we have had some classic, long, ongoing arguments over this. You will find plenty of people on mainly the not to optimize side.

As our scripting evolves and we learn, then little tricks like using ~ instead of != do become readable. As we learn then we try to minimize our impact on the simulators. Yes it is an ongoing argument but an incredibly important one. The new scripters need to learn this also. In nearly any sim you go to, script time is maxxed out. Unfortunately I would bet that 75%+ of the scripts running in SL could be rewritten to lower thier footprint significantly.

When I came to SL I knew absolutely nothing about scripting and have learned. SL gave me the opportunity to learn. But unfortunately some people are more interested in spitting something out that is barely functional and slapping a price tag on it.

So which camp is each one of us in??? Which camp past the optimize versus readability camp. Make some quick cash, or continually trying to improve our skills, continually trying to preserve the simulator resources. Customers will never know if we don't declare global variables and make a sensor or timer constantly ping the server for the info. A customer will never know if we use ~ instead of != -1. But me, I do know if I have poorly written code and it bugs the heck out of me. This has been one thing I have continually asked for. Give us the tools to check our own scripts without having to buy an island. Allow us to ping the server and get script time for just our scripts. Hopefully one day LL will listen.

A simple little tilde ~ isn't such a simple thing after all.

Unfortunately the ones that need to learn this the most won't ever read this. They only come here to poke around the library or the forum to see what they can take and sale. But at least after all of this time there are new people here that are having this argument.

I think you hit the nail on there, at least for me.

is the ~ trick going to make much difference on a one shot state_entry call? no, not really.

is it going to make a difference in a heavy loop? it might, it can add up quickly.

is my code going to be that much more unreadable? maybe, I try to make the code concise through properly named variables, white space to separate different actions and I commentt liberally... and since I know what the operator does in this case, (just had a duh moment on what the number was) the code IS clear... not always the case, but useful here.

if I'm the one to read my code, it doesn't matter... if it must be read by others, it needs a comment... but since I keep a list of all my optimize tricks I learn, it's not so bad

it's funny but the reason I asked was because I was thinking about some examples I'd just added to the wiki, and was still trying to decide whether or not to include the optimizations I did know about... fyi, I do test these tricks using the script in the LSL wiki (LSL Script Effeciency?)

my mind is made up... I'm adding them =)

Don't forget complexity, a semi-close cousin of readability.

End users may not know the details of how something is coded but if it's so heavily tweaked that it doesn't work right any more, they will definitely know..

Huh?????????????????????????????????

Using optimizations to make a scripter faster and easier on the sim. What does that have to do with breaking a script?

Two things.

First, some of the optimizations depend upon undocumented behaviors that could change. In particular, the well-known idiom for reducing memory usage when adding to a list depends upon an evaluation order that isn't documented, as far as I know. It could in theory break if the order ever changes.

Second, when you sacrifice readability, the code becomes more fragile. It's more difficult to tell whether it's been fully tested, it's harder to find bugs via inspection, and it's more likely that changes will introduce new bugs.

Get back to me when LL decides to actually document LSL.

oh YES!! please...

This is so badly needed , in another forum Chosen Few stated in reference to texture size and sculpties that he believed if people had the right information they would be able to make judements accordingly ..

the same goes with scripts. And the first step you need is some sort of feed back about the sort of impact your script is having, what sort of impact changes you make have. Only then can you start weighting effect verses performance. As it stands now most people are coding with only a rough idea, if any, on its effect on performance (either sim or client).

Would such a tool be so hard to impliment?

I think it actually kinda would, at least if such a tool were to be usable without a lot of consideration for "externalities." What seems feasible to me is something that gave an inkling of the execution time a script demands of the VM itself. The problem is that LSL is a scripting language, so the function calls are anything but "functional"--rather, they're mostly called for effect. And these side-effects are where the big sim and client impacts are, and those impacts are massively state-dependent: How many agents are in the sim at the moment to get updated with whatever the script has changed? Have they already received the anim/sound/texture the script is pushing? What other physical objects are bumping around the vicinity? What are the current particle/light source/textureAnim/flexi loads on the viewers' variously dysfunctional graphics cards? Etc., etc.

So, yeah, something useful could be done, one would think, but the scripter still would have to do a lot of "subjective system analysis" in making implementation and design judgments. And unfortunately, the heaviest impacts on sim and client lag wouldn't even be touched by the tool.

This tool I was talking about is already available. It is avalaible to island owners in the estate tools and is called "Get Top Scripts". It returns a list of the scripts using the most ms of script time. It is limited as to what the scripts are doing at that moment but it is still tremendously handy. If you hit the button a few times you can get a really good idea how much time any particular script of your is using and can test with different versions to find the most optimal one. LL can't just let anyone use it as it presently is. As it stands it gives everyone scripts on the estate. The AR's would be never ending if you could use it on your 2048 lot on the mainland and found out that there was one neighbor on a little 512 that was lagging the whole sim.
All they need to do is tweak the present tool so that the simulator will parse out only the scripts that you own.

Still seems like irrational arguments. As already pointed out , if we only used code that was fully documented there would be no scripts.

Secondly, you can only write code and optimize up to your abilities as a scripter. How can you write, or optimize something that you can not read????????? As we learn then we can read and write more. If you know what the tilde does then it is just as readable as a != to minus one test. If you don't know how to use it then you can not use it to begin with. Simple as that.

I can still look at some of Strife's scripts and can only shake my head. To me it is like looking at a foreign language. To Strife, it is just code that he can probably write in his sleep. To Strife it is no harder to read then our codes are to us. When I 1st started, the scripts I turn out today would have been impossible to read at the time. When I look at the scripts I wrote then, I again, can only shake my head, out of pity this time thou.

granted on readability, but I'm a proponent of self documenting code, well named variables, etc... and heavy comments... after having put code down for a year and looked at it again, I learned my lesson quick =)

you never can tell if something was fully tested, ever. as for finding bugs visually, unless it's a complex hack (which should be commented), I have to agree with the previous assertion, that it's a matter of experience reading ANY code... and changes.... heh, everything we do is a hack according to LL subject to change w/o notice, or documentation... so it's a moot point

That's a strawman argument. There's a difference between saying only use code that's fully documented and saying that, in general but not always, issues that affect reliability should be given preference to those that affect performance.


First, you're not just writing for yourself today. You're writing for future maintainers, which may include people less familiar with the idiom. It could also include you after you've been away from coding for a few months. Indeed, it's a familiar phenomenon for someone to write some code Friday afternoon, get back to work Monday morning, and not be sure what the code does.

Second, knowing the meaning of an individual operator doesn't mean a particular usage is readable. Unidiomatic coding is like unidiomatic writing, you can usually figure it out but it slows you down unnecessarily.

Third, lots of people write code fragments because "they heard it was faster that way." I call that optimizing beyond one's abilitiy as a scripter.

Exactly. Self-documenting code doesn't need to be commented as much as poorly written code with obscure variable names.


It's not an either-or situation. Just because you can't be sure something is 100% tested doesn't mean there's no value in writing code for which it's easier to identify a good set of test cases. And yes, experience is very important with regard to reading code. But that doesn't mean that writing code as clearly as possible isn't important.

Here's a thought: It's expected that college-level writing is more difficult to read than middle school writing. That's the difference between James Joyce and J. K. Rowling. But college-level software ought to be easier to read than programs written by middle or high school students. (A gross generalization, to be sure, but I hope it's also a useful comparison.)

As a senior software enginer for over 3 decades, currently working in a respected position in a highly respected and successful major network equipment vendor, I have found -- and the research shows -- that writing code for readability and maintainability counts far, far more than peephole optimization in the vast majority of cases.

Rule 1: optimize algorithms, not code, unless you know precisely WHY you're optimizing the code.

However, in this particular case, I'll admit that Jessee has a good argument that knowing that "~x" means "x != 1" is a good thing to internalize and get used to, and then is not much of a readability block. So my argument for readability is relatively thin.

Jessee also makes a good point that LSL scripts are an unusual case when assessing frequency -- that is, figuring out the rate at which a given piece of code is executed during normal use. For any given script it is normally quite low (with the notable exceptions of open listens), and it's the aggregation of lots of different scripts' event handlers that comprise the bulk of processing resources.

Nonetheless, I stand by Rule 1. That's the rule that makes us avoid open listens, and to consider how often each piece of code will run, and minimizing THAT rather than fussing to eliminate a single opcode here or there. That is the principle that, if taught to LSL coders, will have the biggest impact on overall script latency.

I'm not sure that means anything.

Sims want to run at 45fps. If all the normal stuff of physics and sending updates to residents/neighbor sims and all that is done in less 22ms, the sim will give the rest of the frame time to scripts. A sim running at 45fps with a lot of frame time assigned to scripts is a perfectly happy sim. I think. Hopefully, somebody will correct me if I'm wrong.


/me agrees. This sounds like a coherent version of what Sindy tried to say on the last page.

There really should be a tool for evaluating script performance for folks other than sim owners! Does anyone know of a Jira entry for such a feature?

Frankly, I'd love to see an independent "LSL Underwriter's Lab" to which folks can submit objects and get a stamp of approval if it meets fundamental efficiency concerns. OK, it would be a serious bitch of a job to do this well and objectively, but I'm just pipe dreaming here!

The simplest thing one CAN do without tools is to measure script latency. Run one script that repeatedly sends an event to itself and collects statistics on the response times. Meanwhile you rez a ridiculous number of the script to test and play with it, and watch for correlations in latency.

... hmmm ...

to be continued?