More Memory Questions

Hi all .. another in my string of memry and efficiency questions:

To do a test on a 'boolean' variable we can write the if two ways:

if (var == TRUE)
or
if (var)

Now my question is, exclusing the memory needed to create TRUE (which I avoid by declaring a global constant for true) ... is there any difference in memory used by either option?

Additionally in this line ... TRUE = 1 and FALSE = 0 ... but does the code:

if (Var)

.. evaluate if VAR == 1 or as in some compilers if it is not 0?

Thanks!

do either if(var) or if(!var)...thats the most efficient

Anything over 0 (1-2 billion) is considered TRUE
whereas false is only 0.

Anything under 0 is considered TRUE as well.

Correct...anything but 0 is true...while *only* 0 is false.

Thanks all ... and so for the bonus question:

Which is more efficient or is there a difference:

.......
if (llListFindList (...) != -1)
or
if (llListFindList(...) + 1)
........

........
if (idx != -1)
or
if (idx + 1)
.......

Not an expert in LSL compiler internals but I'd say the two are the same (One integer to store somewhere.) but the first one should be the fastest.

However, to test (any_integer != -1), it's more efficient to use:

if (~any_integer) {}

"~" is the binary NOT and, in binary maths, only ~(-1) == 0 or FALSE.

Strictly speaking, that only applies in systems using 2's complement to represent negatives. Admittedly, nearly all modern computing is done using 2's complement, but signed-bit still exists, in which case ~0 would give you the most negative number the type could represent.

Unless it's buried in a loop or code that executes very frequently, I use

if (llListFindList(...) == -1)

for the readability. Only in rare cases does the optimization suggested matter, especially with Mono compilation available now.

Rule #1: Optimize algorithms, not code.
Rule #2: Learn when Rule #1 doesn't apply

Can't help it! Another readability post. All readability posts have the same commonality; that doing something is "more readable" then doing it another way. Ludicrous!

Lets look at past arguments:

if("something" == TRUE)
is supposedly more readable then:
if("something" == 1)
or:
if("something"

If you know what they all mean then they all mean exactly the same thing and are all just as readable!

if (llListFindList(whatever) == -1)

is only readable if you know that it means; if "whatever"" is not in the list then...

if (~any_integer) {}

is only readable if you know what it means.

SO, if you know what they both mean, how could either be more readable then the other????

EDIT:
Not picking on you Lear! You do a good job of watching script resources with MLPV2. Just get tired of seeing that same old argument and most importantly don't want new people to get the wrong idea about MONO. Just because we now have MONO does'nt mean we have carte blanche. As concurrency rises we have to be ever mindful of resources. There is a movement in the LL ranks to limit scripts in some form or fashion. Limiting per parcel would be one example. Whatever the outcome is eventually, it will have a major impact on the end user. Actually I agree to a certain extent because there are sooooo many shoddy, wasteful scripts out in the grids. It would be nice if we had something like Avatar Rendering Cost for scripts to see just how bad it is.

Honestly, implementing an ARC-like system for scripting would be rather useless and most likely end up causing unnecessary torches and pitchforks to be brought out. ARC is already misleading enough on its own.

As far as readability goes, the majority of work I've seen in SL is unreadable for other reasons and on a larger scale. Most people can't keep their brackets and indentation consistent or do silly things like putting multiple statements on a single line. These are basic coding practices that, if ignored, will make others avoid reading your scripts for any reason. When I'm trying to debug someone's code for them, and I see things like 10 brackets all next to each other on a single line, or all bunched up against the left wall of the window, I usually end up either reformatting the whole script or giving up.

Usually 'something == TRUE' is redundant. I suggest naming your 'something' such that it is obvious to the reader that it carries a boolean value. For example, if you use 'isGreen' then 'if (isGreen) {...}' and 'if (!isGreen) {...}' make sense.

Consider this. Would you ever write 'if ((length < 3.5) != FALSE)'? No. It is clear what you are testing from the comparison. Name your variables appropriately and it should be just as clear what you are testing without the '== TRUE', '!= TRUE', '== FALSE', or '!= FALSE'.

As for the llListFindList() question (and llSubStringIndex() for that matter), I always compare to zero. For example 'if (llListFindList(...) < 0) {...}' or 'if (llListFindList(...) >= 0) {...}'. I know the function is supposed to return the exact value -1 when it doesn't find something, and the closest thing we have to a specification says so, but testing for a negative value not only includes that case makes the logic less dependent on the LSL library implementation. A negative position never makes sense in the context of the return value of those functions except as a special value (not found). It is also somewhat common in library specifications for this type of search to simply guarantee "if the value is not found, a negative result is returned", so IMO it makes the logic a little more portable. I know portability isn't usually one of our large concerns in LSL, but why not catch that low hanging fruit in this case?

I agree 100% with Hewee that "if (x == TRUE)" is redundant. There are valid counterarguments, but still, I tend to barf when I see it. It certainly isn't clearer.

Concerning "if (~llListFindList(...))": despite being a highly paid, top flight software engineer in particularly tough fields (embedded real time control and networking) for over 3 decades, I have to think twice to figure out whether that succeeds if the item is found or not found. To me, the semantics of the "!= -1"form is immediately evident. I'd have to think even harder for "if (!~llListFindList(...))". Sure, just one more negation, but that's also one more chance to slip up. IMHO, this is harder than doing DeMorgan in your head, which I think most of us can do even after heavy drinking.

I doubt I'm unusual in finding the tilde form less clear. Sure, I could train myself to recognize it, but I assume that most coders, even good ones, haven't trained themselves thus. I bet dollars to donuts that if you studied it, you'd find that the "!= -1" form would be misconstrued far less than the tilde form, even if you included only experienced, competent programmers in the study.

I wouldn't criticize someone who used the tilde form in their own coding. It's a nice trick to know. I wouldn't particularly recommmend it for example scripts.

There already is an ARC like system for scripts called Top Scripts. It is in the estate tools and is far from useless, but again, it is limited to Estate Owners and Managers. From some of the code I have seen floating around or sold, a few torches and pitchforks might come in handy. The other nice thing about Top Scripts is the ability to see the affect changes in your code and coding habits have on your own scripts. There are work arounds such as testing code on an empty island and watching script time but it still pales in comparrison.

I almost never say if (something == TRUE). The only time I'm likely to use it in an if statement is if there's something else in there, too. Like, I'll use 'if (a == b && c == TRUE)' instead of 'if (a == b && c)'. They work out the same but one's easier for me to read..



Vote for http://jira.secondlife.com/browse/SVC-835 !!! "Allow 'Top Scripts on Parcel' for mainland land owners."

edit: er.. I see you already did vote for that. Make an alt and vote again!!

Just about every relevant argument has been made on both sides of the discussion and I don't need to weigh in on that. The issue is having your cake and eating it at the same time, in other words, resource efficient readable code. Like all good solutions, it requires you to think outside of the box... er cube (you know it "All begins with a cube" but it doesn't have to end there...). Jesse knows the solution I speak of, it's ESL, it's LSL passed through a C-preprocessor. The advantage is you get to use macros and includes; with clever macros you can have readability and resource efficiency.

Except that they aren't all the same.

TRUE is defined as the integer value 1.

if (something == TRUE) will only execute the conditional statement(s) if something has the value 1 in it.

if (something) will execute the conditional statement(s) if something has any value other than 0 in it.

For LSL, if (something == 1) is identical to if (something == TRUE), but to me, it has a different meaning; that something is not a Boolean, but is meant to have integer values, which could be anything, including 0 or 1 (FALSE or TRUE).

It is all because LSL is based on C, and C doesn't have true Booleans (Booleans are not integers, but are represented as integers in C to simplify the compiler). As a result, you can write (bad) code which mixes up the meanings of integers and Booleans. For those who understand this, it DOES affect readability.



Well, there's only a couple ways that the first one makes sense:

if (llListFindList(whatever) == -1)

or

if (llListFindList(whatever) < 0)

Since the definition of the llListFindList function specifies that -1 is an in-band signal that the target was not found in the list.

As for:

if (~any_integer)

that reads as nonsense to me, because it is treating an integer value as a Boolean, because the use of a bitwise (integer) operator specifies such. It leads to people having to work out in their heads what bitwise values would lead to both true and false conditions and is, thus, less "readable" than the comparison operator.

Just like with natural languages, there are also subtle nuances in the way we do things in programming languages, which can change the interpretation and readability of a particular piece of code. Those nuances are not always readily apparent to more neophyte programmers (not a slight; we all were neophytes at one point!), but over time, they become important signposts for how we write and interpret our code, even for ourselves.

Whichever operator you use, you still have to work out what it does (to complicate things there are 6 comparison operators which can be confuse with the assignment operators).

Not to be a pain but that logic just doesn't stand up (you haven't demonstrated that it is harder). People should be well versed in how the operators work after all they are the most basic and inescapable part of any language. Doing a little bit arithmetic isn't that hard once you learn the tricks. Everyone should know what 0 and -1 invert to.

Wow .. what a can of worms I opened ..

Thanks all for the comments. I normally will tend to code more towards readability first, but there are cases (and a script I am working on at the moment is a case in point) where I need to squeeze out every byte that I can .. thus my initial question.

In the end what I have getten from this is that:

if (var == TRUE)
uses more memory that
if (var)

BUT
if (llListFindList(...) !=-1)
is the same as (memory usage wise)
if (llListFindList(...) + 1)]

Thanks again all!

LMAO Any time the topic of optimization or efficiency is raised the same thing happens. People confuse readability with the way they like to do things. If you can read it then it is readable.
But it is always nice to see scripters get to the point of asking how to make thier code more efficient!

Readability is measurable and quantifiable, and things like the "~" optimization are clearly far more difficult to process. Especially when you have to then negate it!

I'll repeat this, because it's really the right way to think about the vast majority if coding: Optimize algorithms, not code. Most time spent optimizing code by less experienced programmers is wasted in two ways: (a) it's optimizing code that doesn't affect performance measurably, and (b) it obfuscates the intent.

However, if "~llListFindList(...)" is readable and clear to YOU, then that's what matters! Use it with my wholehearted blessing. If you have to think twice to remember just what it means, then don't unless there's a clear need to optimize that particular block of code.

Of course, if you're writing open-source code, or code intended as a functional example, I suggest avoiding the tilde trick, because you'll be making the code harder to follow for a substantial portion of the audience.

I should have been clearer in my original post that for clarity, it's the audience that counts. For most scripting, the only audience is you the coder, so clarity to you is all that matters.

Back to the original question, the correct answer was in the first response: use "if (var)" or "if (!var)".

"if (var)" is semantically equivalent to "if (var != 0)", but takes less opcode space, and is more readable, assuming you've named the boolean variable well.

However, your question contains a false assumption.

Using a variable to hold the value TRUE uses memory. Probably more memory than using the built-in constant, but maybe not, depending on the internals which I haven't inspected. But using a variable costs space in two ways: (1) the variable itself, and (2) the reference to the variable.

Using a variable to hold NULL_KEY saves space, because that's a big literal. TRUE is a small literal, and for most real machines, the reference to the variable takes more space than the literal constant in the instruction stream would. For virtual machines like LSO and Mono, it could go either way and you'd have to know the byte code details to answer it -- but most likely, using a variable wastes space unless the constant is bigger than an integer.

One more parting shot.

I've worked in teams of programmers for over 30 years, and believe me that for professional coding, it's extremely important to write code that's clear to the kind of programmer working on the team. Sure, people disagree about what's clearer -- there is a lot of gray area! But it's best when the team comes up with a style guide that they can all follow to make code consitent and clear.

When you're coding for yourself, you're a team of one, and you get to pick your own conventions. Do what works for you! But it's still best to have a set of conventions.

(Do as I say, not as I do, because working on open source code, I sometimes follow the conventions in the existing code, sometimes my own personal conventions, and other times I accidentally fall back into conventions I use at work. So, please don't use my published code as an example of this point!)

Just to clarify, for float and integer constants (be them named or inlined) the cost of having them inline is the same as having them in a variable (global or otherwise) but you also incur the cost of the variable in stack space and bytecode space via declaration. While it is convenient to use a variable to store a float/integer constant, it doesn't pay off in performance or memory; the only benefit is readability.

The same can be said for string/key constants that are shorter then 3 characters (in LSO). Longer string/key constants, vector and rotation constants benefit from being put into a global variable as long as you use them more then twice.

Oh and Lear is right, know your audience, save yourself a lot of work down the road and make it readable... memory fades, comments don't.

Some parts we will never agree on such as that statement. Sorry but I am 50 years old and my mind and memory work just great. If I use this snippet today in a script:

if(~llListFindList(["red"], ["red"]))

Then I would have no problem remembering a year from now what it means. If you know what it means then you always know what it means until maybe alzheimer's sets in. Why someone with much more experience seems to have a problem wrapping their brain around it or find it "difficult to process" is in itself difficult to process. I also don't understand why either here or in other coding forums when someone does not have a logical argument they start pulling out their credentials to try to add weight to an empty argument and start throwing around phrases like "Most time spent optimizing code by less experienced programmers is wasted". It is insulting and is a thinly veiled attempt to belittle the contribution of others.

The same goes for posting example scripts. When I was learning I didn't want to just see just plain vanilla ways to script something. I wanted to see how everyone scripted the same thing differently. Let people grow and learn, make them think and use their brains. I used to absolutely love coming across conversations like this in the forum. So many passionately felt and diverse opinions. There will be twenty or 30, maybe more, newer scripters that will read this thread 3 or 4 times and each will absorb something from it.

Add structure and regimentation to your code or throw the rules out the window and free your mind, play, learn and have fun creating.

Or is it actually a combination of the two?