bad Loop causes massive ruby shutdown

[billv]

I've never seen 'a ruby companant shutdown' happen this bad....
While inside main fsm, i added a bad loop...
about 80% of all ruby componants in entire fsm were turned off for excessive processing.
Thought I'd mention it in case there were more noobs out there playing with loops..
Practice loops in isolation....

ScreenShot307.png (94.72 KiB) Viewed 14847 times

[RJHollins]

oh yeah ... the 'Red Rings of Fire".

One time in particular, I had just saved the FSM. I stuck something into a RUBY and flames everywhere. I ended up reloading the FSM [DO NOT SAVE] . The time to reset everything, it was faster to re-load and try something a little less combustible

[trogluddite]

A "global" reset for the Ruby prim's would be nice though. If you know what bit of code just made the problem, it's often very quick to fix, but going through all of the modules to reset them is really time-consuming.

[billv]

going through all of the modules to reset them is really time-consuming.

they were all frozen...couldn't re-open...
brought in new ruby module and tried to capture offending code for reference...froze as well..
I think maybe if i removed all module links..may have unfozen it...
but didn't try...schematic too big...just bailed out...
should have saved it under alt name to re-investigate.... ...bummer

[Walter Sommerfeld]

Yeah - it's really a mess - even if u only have 70 rubies in ur schematic ...

A "global" reset for the Ruby prim's would be nice though.

Yup - we miss this button...

[tester]

Try opening the schematic not by clicking on it, but by loading to opened FS. And try to load something else/working first. Maybe this will "reset" the rubyish part.

Just recently ruby started to crash my project on start, but after I did as I said above - I could load the project again. It's probably one of these awkwardnesses...

[billv]

What about an 'display' in debug window, that shows how much processing
your code is using..... ??

It's like tester mentioned in other post, it's really hard, being a noob to ruby, to
understand fully what's going on....

Here's a good example of what i mean...

This fist loop runs in about "a blink of an eye'..

Code: Select all

def event i,v

if i == 0 then

for i in 1..1000 do
output 0, i if i % 7==0
end

end
end

In th 2nd copy, I've made 1 change, adding a control variable,
And now it takes a full 2 sec to process....

Code: Select all

def event i,v

if i == 0 then

for i in 1..1000 do
a = i if i % 7==0
output 0, a
end

end
end

Point is....
It looks like you need "solid" coding skills and "understanding" to get the best out of ruby.

Not knowing stuff like this is making my current project run at 3 times the normal cpu cost....
It's becoming more clear to me that trying to improve my project using ruby is almost pointless..

When i put my current project version up against a older green version.....
the evidence is frightening ....and just keeps piling up......
Green versions run as smooth as butter...current version is like f##king sandpaper....
A million green prims run smoother than a few thousand rubies....

And tester thinks "he's " fustrated....
I'm so close to shutting down and going back to making albums....it's not funny...

[tester]

Yep, your frustration is definately larger than mine

[Tronic]

You have to take into account that every time an input or an output is fired,
the ruby starts a thread, it processes all in ruby.dll and returns the result of closing the thread.
FS and Ruby are not multithread, all threads are queued and executed.

So in each loop should exclude, the input and output and manage the allocation of them outside of the loop.

[trogluddite]

It looks like you need "solid" coding skills and "understanding" to get the best out of ruby.

But surely that is always true - it would be equally valid to say...
"You need solid trigger prioritising and optimising skills to get the best out of FlowStone's graphical programming language."

All languages have their strengths and weaknesses (and I include "green graphical" as a programming language) - and all programmers have their own unique styles/talents that suit some languages better than others.
Ruby is not a panacea - there are undoubtedly many situations where green primitives will perform better. So neither way is "better" - but each may be "better suited" to either the situation or the programmer.

In th 2nd copy, I've made 1 change, adding a control variable,
And now it takes a full 2 sec to process...

Not quite - you have made two changes - and the second one is the most critical for performance.
In the second example, you have introduced a new variable AND you have taken the "output" command outside of the "if", so it is no longer conditional. (when "if <condition>" is at the end of a line, it affects only that line)

So iIn the first code, you only get an output when you find a multiple of 7; in the second, you send an output for every single iteration - so 7 times as many outputs. As Tronic says, this will cause "grid-lock" at the green output, due to the limited speed of green triggers - so it's most likely the clearing of the output triggers that is slowing things down; there's no reason that the Ruby loop itself should run significantly slower.

There's also something else odd happening. If 'i' is not a multiple of seven, the variable 'a' does not get assigned, and "output 0,a" isn't sending a useful value.
That's because the bit in between "do" and "end" counts as a 'block' of code. Within a 'block' any new variables that get declared are always 'local' to the block, and get destroyed as soon as the block ends. In your loop, the variable 'a' is created and destroyed for every single one of the 1000 iterations, and 6/7 times is never assigned a value.
You can see this in action in this example...

Undeclared in Loop.fsm

(317 Bytes) Downloaded 854 times

Luckily, the conversion to "green" does handle this without a Ruby error - but the 'nil' is converted to the "default" value of zero - so all of those extra output triggers are also sending invalid data. In some cases the undeclared variable would lead to Ruby crashing.

Well OK, so there's some more Ruby weirdness to try and commit to memory - but that's not really the important lesson here.
The real lesson is that you cannot compare the performance of two codes unless they are semantically the same - i.e. the same input conditions produce the same output conditions (with the same timing, if that is important).
And after all this Ruby talk, it's ironic that our biggest friend here would have been the old, faithful "Green Trigger Counter" - it would have shown that the two codes were doing different things very quickly!

On a more practical note, if you want to get some comparative data for the running times of different Ruby codes, you can use this little technique...

Code: Select all

@start_time = Time.now

## CODE TO BE TESTED ##

watch "Elapsed", Time.now - @start_time   #=> Elapsed time in seconds

Note that it's 'Time' with a capital 'T' - a built in Ruby class that reads the system clock. Lower case 'time' is the internal FS Ruby clock, which may not be so accurate (it only updates at 100Hz when there's no audio connection).