billv wrote: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.
billv wrote: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...
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).
...bummer
...
??
