DSP Robotics Support

Hi all. When I made some own modules, I often got several ways to get the same results. Finally I choose the one that spends less CPU cycles or RAM or another efficiency feature. Sometimes I can´t to see which ones spend less of that charges.
If anyone has the same problem that me, I propose to post here that modules (in OSM or screenshot), so anybody can help with the choosing, adding short explanation.

I start with an example. It`s a real doubth from mine, so please help

This is a very interesting idea for a topic. In most cases I won’t be able to help but I hope to learn from anyone else who can give explanations.
I do know that the number of triggers generated when something changes is important, so one thing I could suggest is to make use of the trigger counter module as a basis for comparison. But that doesn’t take into account of what happens “inside” the various prims.

Cheers

Spogg

Interested too !

Hello!

When i want to test something on CPU usage and compare it - i do a loop an call it "a lot" like here 1000000 times.
Then i do a measurement from the time it needs. The lower time - the more cpu efficient

I made a tiny schematic with an time-measurement that calls the selecter and the array in the same way - including at least one "Int-Input-Box" to show the value and simulate to do something.

Results:
On 1000000 steps the selector needs: 0.496 seconds to complete
On 1000000 steps the array needs: 0.437 seconds to complete

Something equivalent in ruby by array need 0.073 seconds.

Warning:
Do not match ruby and green! Ruby and green are running dethreaded and would not deliver the correct time-measurement!

Edit and Summery:
It seems the Array is a little faster - and i think it is more comfortable to use.
If you want to built something that need realy cpu efficiency you should go into ruby and stay there until you got the final results and then pass them to green.

Regards, C.Hackl

very cool C.Hackl

thanks

Just make sure that any tests involving Ruby stay a good portion under 10 seconds, as this is the latest at which Flowstone will automatically shutdown Ruby assuming an infinite loop.

EDIT: And a reminder that the array example only was slightly quicker, because the get at prim sends no backtriggers but stores the converted array (and so no string to array conversion on each "get at" takes place). This is not always the case! A lot of prims do use backtriggers.

tulamide wrote:Just make sure that any tests involving Ruby stay a good portion under 10 seconds, as this is the latest at which Flowstone will automatically shutdown Ruby assuming an infinite loop.

EDIT: And a reminder that the array example only was slightly quicker, because the get at prim sends no backtriggers but stores the converted array (and so no string to array conversion on each "get at" takes place). This is not always the case! A lot of prims do use backtriggers.

you make an interesting point regarding the array

I am happy with all the posts, and I am glad that them make interest for several people. Go ahead!

You forgot another primitive, if else. It'd be sensible to test it against that, also the index selector come to think of it. Just name the string number names, does the same.

Makes Me curious,

Good sugestions! Thanks.