Question re: Loop use and intensity

[Chrille]

I'm cleaning up some of my code and using more loops generally leads to clean-looking results. However, I've always been reluctant to use more loops than necessary and I'm curious about whether it's the amount of times a loop runs vs. what happens in the loop that puts the biggest load on fusion.


For example: I've been using a loop that checks the array contents surrounding a given pair of XY coordinates. The loop used to look something like this:

+On Event
- Start Loop "scan" 1 time

+On Loop "scan"
+ArrayXY (X+ -1, Y+ -1) == bla
- Trigger something 

+On Loop "scan"
+ArrayXY (X+ 0, Y+ -1) == bla
- Trigger something 

+On Loop "scan"
+ArrayXY (X +1, Y -1) == bla
- Trigger something

(+ 5 similiar events)
etc...

... that is, one event for each of the 8 array slots to check.


I cleaned it up, and now the loop is called once for each slot instead, like this:

+On Event
- slotX = -1
- slotY = -1
- Start Loop "scan" 9 times

+ On Loop "scan"
+ArrayXY (X +slotX, Y +slotY) == bla
- Trigger something 

+ On Loop "scan"
- slotX++

+ On Loop "scan"
+ slot X > 1
- slotY++
- slotX = -1

I haven't noticed any difference in performance so far, and the second is preferable as it's much cleaner. So I basically I wonder what's generally the best practice here

[schrodinger]

I've spent some time tweaking and optimizing and testing speed differences,
I can share my own experience but it's of course limited to what I've done, so can't be considered a general practice (disclaimer )

Unfortunately it's very hard having a real best practice as things involved may vary depending on what you do within your loops.

In your situation I'd say "loop-wise" it should be "about" the same
(firing 9 times vs doing 9 calls - 9 calls could cause a minimal lag arount the order of millions operations),
and as long as you perform the same number of reads from the array,
which are the bulkier thing inside that loop, all considered both approaches should be about the same.
Setting and comparing values is very quick, but yes, it's some operations more,
so if I had to bet, I would expect -on huge number of iterations- a very small additional lag on second approach
but since we're talking about very minimal differences they probably compensate each other.

I think cleaner code is anyway better, even (if) at a very small cost,
as long as this lag is unnoticeable -- not a concern in your application.

If you're interested I should have a -very rough- but effective speed tester somewhere you could use to have a real answer
(test version 1 vs version 2)

To add some info for the casual reader,
writing & reading from alt. values / global values is the fastes thing Fusion can do
and standard array is one of the quickest database systems Fusion has,
writing/reading the array takes about twice as doing it on values
(can remember it being almost the best result among similar objects)

[Chrille]

Thanks for the thorough explanation, schrodinger!

Thanks for offering the speed tester, I'm happy with how it is now though and don't feel the need investigate further. Although if things get worse later on, I might come crawling back

[schrodinger]

Yeah no problem, speed tester is always here

Out of curiosity,
since I took back that tester,
I tried firing a loop:

4.000.000 times
on loop >>> do this

and 2.000.000 times
on loop >>> do this
on loop >>> do this

results showed a total average difference of +2 hundredths of seconds in the second way
thus indicating that from scratch it's a little bit slower


A little OT,
but since I was testing with HTML5 exporter also,
I made an HTML5 vs Windows speed test
and surprisingly discovered that
(in this very specific test situation, of course, but can be interesting to note)
HTML5 runtime is only 4.69 times slower than Windows runtime

(I was testing doing math calculations on a loop)

I was expecting worse results, think it's pretty good!


EDIT____

btw, this leads me to add that all above considerations about speed were aimed at Windows runtime,
very likely if you're developing for other platforms these very small numbers could become moderately important

[Chrille]

Interesting! So I guess it's slightly preferable to have the loop run more times with less action each/LoopIndex instead.

I've been using the Android exporter a bit and that certainly behaves different from the Windows runtime. Have you used it?

[schrodinger]

Unfortunately my testing on Android has been very limited so far
(the fact that I don't have a smartphone nor a tablet doesn't help )

I'm testing on an "android emulator" for pc and it generally gives similar results to things I see in friend's devices
(emulator should also emulate the system "slowness" being a virtual machine - does it pretty well )

But I've run into the impression that looping is quite dangerous there,
i.e. my experience with the Pathfinding Widget seemed to show that the recursiveness needed by the engine
was barely held by the android runtime.. like working one out of ten times (9 times crashing..) and just once per run (!)

But I'll return back on that widget and try to find out if something else was causing issues,
of course it may be something completely different I've overlooked,
definitely not sure it was the high number of looping alone.

I.e. I've seen that:

1- null values in arrays caused crashes in Android (while Windows runtime reads them as 0)
2- alt. values past 26 caused crashes in Android

(EDIT: sorry ^ these two bugs applies to HTML5 exporter not Android! Memory fault)

Sorry I may be going a little O.T. here but I think it's very worth talking about this.

I was thinking one day to crawl the Android forum section and look for a place where such doubts-questions are collected,
if such a place does not exist - maybe we (the community) could put up a sticky with this kind of issues / things to look for when exporting,
I've seen Jeff did this for extensions, very useful. We should do this also for "standard" features not covered / still buggy in Android and this ^ kind of things, like "how much looping can Android bear?".
Or maybe a section in the ClickWiki? Would save us tons of time testing.
I remember other community members asking for this time ago - I would definitely agree and add the few things I've discovered!

[Chrille]

Cool! I didn't know there was a pathfinding widget. Would be interesting to see it!

I made a pathfinding system for my game as well, and that happened to be what me cleaning up the code with loops was about . I don't remember the logic I had when putting it together, but I was surprised it worked so well. Here's me putting it together:




Re: null array data. I don't think I've had any crashes from that. Is null data considered a slot that has yet to be written to, or a slot that is outside the current XYZ dimensions?

I think I putting together a sticky thread, or a wiki, for Android-related issues is a great idea. Aside from bugs and odd behaviour there are some functions like Load Frame and Replace Color that aren't supported on Android that don't have an official mention, afaik, for example.

[schrodinger]

Cool! Did you test your pathfinding code on exporters?
Something reliably working on Android would be much useful!

Here's my work on the "easy-path" widget:
http://community.clickteam.com/threads/94895-Easy-Pathfinding-Widget-%28extensionless%29?p=678389&viewfull=1#post678389
(latest version should be on 16th post, the one that should pop out clicking link above)

This is a HTML5 test of same widget:
http://lizardking.co/easy_path_widget/
Mostly works, beside color blitting (definitely a side-feature..)

It was a quick test to relief a little from other project at time, so I didn't refine it completely,
I would like to improve/fix it in the near future though.

aaaannd -
gosh, re-reading that thread I found out the the null-values and >26 values bugs were both on HTML5 not Android
heck, sorry for messing up! Memory played a bad trick,
glad that "Android missing features / bugs" thread still don't exist so I didn't put something wrong in

I'd say we'll have to bring this up in the Android section someday,
hearing experience from android-clickers could be very useful for everyone.

And I guess the same should be done for every exporter.

[Chrille]

I only tried it on the Android exporter. There were noticeable framedrops when the path was too long, but as the function doesn't run very often it's not too big of a problem. The biggest load on Android seems to be the dynamic loading of the levels. Creating & destroying objects, especially combined with a loop, is a big no-no.

It's been a few months now since I tried exporting the game to Android though, and the creation/destroying of objects is now on a very low scale rate. Excess tile objects are moved outside the game window and then just moved when they're needed. All my tile graphics are storied in different anims/dirs/frames though, and I'm not sure if jumping between those also put a significant load on the system. It also seems that Android prefers less, but larger objects to many small ones. I last increased the performance a great deal by merging smaller tiles into a few larger ones. Anyway, it will be interesting to see how it all behaves once I try exporting it again. I read that the latest beta appearently performed worse then previous ones.