Which is better for realtime performance?

[kortezzzz]

I'm wondering a long while which combination of PRIM's \ ruby is better when dealing with the need of decent real time performance in projects. Uploaded 5 pics of examples with combinations that in many conditions, do the same
thing. But surely some of them are better choices in terms of performance. Maybe the gurus may shed some light?

Here they are:

[martinvicanek]

Why worry about green stuff and ruby? For live performance your primary concern is latency of the stream data. That is a matter of choosing an efficient DSP algo together with a good implementation, often in assembly. Nothimg to do with green or ruby.

[kortezzzz]

Why worry about green stuff and ruby

Because I use a huge amount of them
My project doesn't contains any stream data at the moment. It's a pure midi project. Maybe later I'll combine stream.
Anyway, it's a principal question. AFAIK, each primitive has it's own cpu\ram consumption so I think we better know it.

[Exo]

Only way to know for sure is to test them.

Any differences in CPU use between primitives and Ruby components will depend on usage. For instance passing an integer into a Ruby component, multiplying it and passing it back out will be slower than just using a multiply primitive. This is because the integer is converted to a Ruby class and when outputting it is converted back to a normal green Integer.
So it is highly likely that small snippets of Ruby code will be slower than the same using primitives. But on the flip side I would expect large amounts of Ruby code to be faster than a large amount of primitives. This is due to the overhead of the event system and triggers. But this is mostly speculation on my part I have never compared the two.

So as a Rule I would say avoid lots of very small snippets of Ruby code connected together in 'green'. Either do it all in green, or for large amounts of primitives or small Ruby components consider rewriting it all in Ruby.

[Xtinct]

Ditto for stream

[tester]

As for green prims - keep in mind, that some of them perform slightly diferent functions and behave differently in regards to triggers (both, active and passive). For example select prim vs trigger switch prim or sample and hold prim vs trigger switch prim.

As for small ruby codes - like Exo said. Avoid having too many small ruby windows. Either focus on greenery (they are just a visual representation of the same amount of written code) or move all into larger ruby modules.

Also keep in mind, that in certain situations - ruby based stuff may behave differently than greenery,. Ruby works on single interpreter (one issue stops all operations), while greenery works locally and depends on FS core. FS core is more resistant to problems than ruby so to speak.

If you have a lot of green stuff, that is the same (synchronized) - you may consider pushing data either through paralel modules that do the same stuff or - switching data through single module.

[kortezzzz]

Thanks for the useful info, guys. I do use lot's of small ruby codes and seem like I'll have to take another look at the schematic, according to your suggestions. In some cases, It's really hard to avoid of small rubys because sometimes
you need ruby to make a small local task that would save a lot of green wires (like ruby hashes module), so the question is if it still worth to go to ruby and save time, or make the extra effort and draw a bunch of green spaghetti.
Saying the truth, personally, I prefer the old visual greenies, but can't ignore ruby's power, especially when dealing with midi, compared to the green solutions. For instance, editing midi features by using midi split\midi event combination; I doubt if its faster than 2-3 ruby modules, as it looks s-o clumsy! Maybe I'm wrong, but for instance, when I compare between ruby's and greens solution for keyboard spliting, it's hard to believe that greens are faster.
Anyway, the point of this post is not only to compare between ruby and greens but also greens and themselves.
For instance, the green selectors (the first picture in my post): Its just me or the 2 inputs selector responds a lot smoother to fast on-off switches? And theoretically, They do exactly the same thing in most cases...

[KG_is_back]

From what I've noticed, avoid green loops (the loop prim for example) especially when handling individual elements in arrays (like filling array via green loop). Instead use ruby or analyzer primitive (with array to mem and wave read prims, to do the tasks in DSP code). Green is limited to 100triggers per second. Filling an array with 100+ elements in green causes freezes like crazy, when computations of individual entries are massive, and when you rewrite the algorithm to use ruby or DSP code + analyzer prim instead, the operations are almost instantaneous. Also avoid text prim connected to/inbetween array links.

[tulamide]

And since you asked for green/green comparison, as a general rule of thumb:
The more connectors a prim has, the more likely it will be slower. You won't notice it normally, but when we're talking of hundreds or even thousands of those prims in a schematic, it will be evident.

The thought behind it is the following:

Imagine you have to decide, wether left or right incoming data is to be preferred. You look at both inputs, and whatever comes first, will be send out by yourself.
Now imagine the same procedure, but we are not telling you how many inputs there are. So you first have to look for the amount of inputs, then check wether left or right comes first, and the next time you again have to check how many inputs there are.

A simple example, but the basics are true for everything that's computed.

[RJHollins]

rookie question coming in

What happens [speed execution wise] when a FS schematic is exported as an .EXE or VST ?

Is eveything the same as within the 'interpreter', or is the export compiled into code ?

thanks