Roku Developer Program

[Komag]

IF mAA.stepping
	IF mAA.facing = 0 THEN mAA.curY = mAA.curY - 4
	IF mAA.facing = 1 THEN mAA.curX = mAA.curX + 4
	IF mAA.facing = 2 THEN mAA.curY = mAA.curY + 4
	IF mAA.facing = 3 THEN mAA.curX = mAA.curX - 4
END IF

OR

IF mAA.stepping
	IF mAA.facing = 0: mAA.curY = mAA.curY - 4
	ELSEIF mAA.facing = 1: mAA.curX = mAA.curX + 4
	ELSEIF mAA.facing = 2: mAA.curY = mAA.curY + 4
	ELSEIF mAA.facing = 3: mAA.curX = mAA.curX - 4
	END IF
END IF

(I personally always leave off "THEN" when I'm doing multi-line IF THEN blocks)

So the question really: Is a set of four single line IF THEN statements run more efficiently under-the-hood in BrightScript than a single block IF THEN using multiple ELSEIFs?

[greubel]

Personally, I would say the elseif is more efficient because if the value was 1, it would skip out on the second test.
But if you are in doubt, put both in a loop of 100, set the value for 0 to 4 and time them.
Never know for sure what BRS will do without testing it.

[dev42]

"Komag" wrote:
So the question really: Is a set of four single line IF THEN statements run more efficiently under-the-hood in BrightScript than a single block IF THEN using multiple ELSEIFs?

I prefer Option C ( which a few of the Gurus would have to approve / improve on 😞

Direction could be a vector... Up == (0, -1), Down == (0, 1), Left == (-1, 0), Right == (1, 0)

Then after checking for isStepping, no more IF's:

curX = curX + 4 * Direction.X ' or ... direction[0]?
curY = curY + 4 * Direction.Y ' or ... direction[1]?

I'll add that I've been taught (*cough* EnTerr *cough*) that using dictionary look-ups is slow and something you don't want to do in a loop. I've not tested this or know for fact how slow it would be to use a Dictionary ( roAA ) of only 2 values { x : ?, y : ? } But either way, converting that to a roArray wouldn't be too difficult / confusing to follow ( with a comment line or two ).

Yet, the dictionary look-up "performance hit" might have more to do with using the roAA "mAA" instead... dunno.

I'll also add that this "solution" might actually be slower! due to having a multiply instead of an add... but I like it better for unknown reasons. 😉

Finally I'll *ADD* one last tid-bit... as stated, if you don't nest your IF's your code will be doing extra work on average, BUT the nested IF's won't be a uniform amount of time thru that part of your code. *THAT SAID* does any of this really matter? Isn't this a very small optimization in the whole scheme of things?

As difficult as it might be, not that I do this first and foremost, but I'd say go with readable/maintainable code and optimize it later when/if you *NEED* to.

"Premature optimization is the root of all evil (or at least most of it) in programming." -- Donald Knuth http://en.wikiquote.org/wiki/Donald_Knuth

peace, Happy Thanksgiving & 42

ps - I tried... I really tried *not* to make mention of this being my 42nd post. So, I won't. 😛

[EnTerr]

"dev42" wrote:
I'll add that I've been taught (*cough* EnTerr *cough*) that using dictionary look-ups is slow and something you don't want to do in a loop.

Bless you! If i haven't said it, i'll repeat - "in a tight loop", meaning speed-critical. I'll bet money here that's a YAGNI, need not worry about that.

I've not tested this or know for fact how slow it would be to use a Dictionary ( roAA ) of only 2 values { x : ?, y : ? } But either way, converting that to a roArray wouldn't be too difficult / confusing to follow ( with a comment line or two ).

Yet, the dictionary look-up "performance hit" might have more to do with using the roAA "mAA" instead... dunno.

I'll also add that this "solution" might actually be slower! due to having a multiply instead of an add... but I like it better for unknown reasons. 😉

I like it better too. And to avoid multiplication, how about encoding the speed vector instead of single `mAA.facing` into 2 components (dX from delta-X, incremental step in X direction):

mAA.dX = 4
mAA.dY = -4
...
mAA.curX = mAA.curX + mAA.dX
mAA.curY = mAA.curY + mAA.dY

Now regarding multiple IFs, i usually take the "else if ..." chain approach because i have been burned quite a few time by side effects of previous IF on a later IF when they are not fenced off. E.g. say one of these IFs changes mAA.facing (maybe not right now but in future version of the program) - then weird things may happen. It's a bit of defensive programming.

[EnTerr]

"Komag" wrote:

IF mAA.stepping
	IF mAA.facing = 0: mAA.curY = mAA.curY - 4
	ELSEIF mAA.facing = 1: mAA.curX = mAA.curX + 4
	ELSEIF mAA.facing = 2: mAA.curY = mAA.curY + 4
	ELSEIF mAA.facing = 3: mAA.curX = mAA.curX - 4
	END IF
END IF

Oh, by the way - this format you show - it shouldn't even compile, if you ask me!
You are shaving too close to the skin for this to feel comfortable/safe. Slightest change - missing the ":" (what i'd call "destruk style") or replacing it with "THEN" - makes this stop compiling:

	'no go
	IF mAA.facing = 0   mAA.curY = mAA.curY - 4
	ELSEIF ...
	ENDIF
	'no good either
	IF mAA.facing = 0 THEN mAA.curY = mAA.curY - 4
	ELSEIF ...
	ENDIF

The exact syntax you used is not documented and with a minor change of the compiler may stop working. I suggest for block-IF put then-branch statements on separate line, that works with all 3 styles:

	IF mAA.facing = 0: 	'or `IF mAA.facing = 0` or `IF mAA.facing = 0 THEN`
		mAA.curY = mAA.curY - 4
	ELSEIF mAA.facing = 1: 
		mAA.curX = mAA.curX + 4
	ELSEIF mAA.facing = 2: 
		mAA.curY = mAA.curY + 4
	ELSEIF mAA.facing = 3: 
		mAA.curX = mAA.curX - 4
	END IF

[Komag]

Hmm, I'll consider, but the colon : is simply documented as:
"Each line may contain a single statement, or a colon ( : ) may be used to separate multiple statements on a single line."
(http://sdkdocs.roku.com/display/sdkdoc/ ... +Reference section 2.0)
So I think it's pretty safe with future compilers to use a : sometimes instead of using a new line.

I too have gotten in trouble with all separate IF THENs when something was changed in an earlier one and then picked up by a later one and changed back! But on the other hand, often I need them separate so each thing will be checked regardless. Other times I just like to make my code line up and look pretty! 😄