Nesting- What it exactly does?

[kortezzzz]

Working on a very big project lately that combines samples and midi sequencing and following exo's great article about reducing loading times, tried to un-nest my project wherever it possible.

The results:

Amazing reduce of RAM usage from approximately 1.3gb to 560mb and super smooth sampler's behavior (10 samplers ) like never before! (Thank you exo for your priceless article!!)

Well, the question what nesting action actually does? And why is it so expansive in resources? When we should nest and when we shouldn't? This enigma is really interesting point in FS development and should be known to the community.

[MyCo]

Think of it like that:
Every module and primitive is a C++ class. This class handles the drawing, all the modules GUI actions, the Input/Output (wich are classes with additional properties), and modules even store a sub schematic. So every module although it might be empty uses an overhead of memory to store the code/structure for its actions and properties. On a flat structure you basically reduce this overhead.
For the CPU, there might be a benefit in a flat structure for triggered data (green/ruby), because the triggers don't have to pass through the parent modules class, which looks up how to pass it to its child components.
However for stream data it shouldn't matter, because stream code is compiled to a flat structure everytime the stream section changes.

[Exo]

My rule of thumb is just to nest as much as makes sense too.

It is all about organizing the schematic so that it is readable and maintainable. If you didn't organize into modules then changes are much harder to make.

So it is finding the right balance.

MyCo has given a very good answer to why there is overhead for modules and especially deep hierarchies.

So my advice is to use as many modules as you need but where ever possible try to keep them "flat" and avoid pointless modules within modules that are doing very little.

[kortezzzz]

Thanks for the answers, guys. So, just to simplify the explanation for those which don't understand a thing about classes and coding:

1) Stream data can be nested without a worry as long as it doesn't contains any green\Ruby code

2) Green\ Ruby nesting creates extra CPU\RAM overheads because of the difficulty to pass off through to child components that nested deeply, so (lets ignore the schematic cosmetic organizing for a moment), it's highly recommended to avoid of nesting green\Ruby "hierarchies". So theoretically (as it impossible to avoid nesting at all) the best performance schematic probably would be a "single nest" schematic.

Am I right?

And what about visual components (yellow)? Are they related to overheads creating as well?
For instance, the stock SFZ multisample player module has in it a kinda nasty and chaotic sample graph drawer with a lots of un-connected prims in it. May that part harm performance and maybe better to be deleted?

[Nubeat7]

one way i use to avoid deep nesting is, using ruby, 1 code component really can save several green levels..

i also extract all GUI elements from the stream parts so that they are not placed somewhere in the 5th level of some stream modules and you need to go another 5 levels down to change some behaviour of your knob..

the deepest levels in my schematics are normally max 5 levels deep - specially on more complex GUI controls - the stream related modules rarely are deeper than 3 levels anyway...

here for example you can see the first level (directly below the surface) of bondage, from here you can go maximum 4 levels down

bdg.png (42.16 KiB) Viewed 9887 times

about deletion of unused things, sure everything which is not needed should get deleted, also float, integer,or string prims which are through positions (which have an input) are senseless, often its needed in the development phase to control values but all the "watch" elements should get deleted in the release versions, normally it doesn't or shouldn't affect the performance but the size and the loading times, same goes for help texts or info panels which are seen just in FS (use purgeable for things which shouldn't get deleted but not needed)

[kortezzzz]

@Nubeat7,

Thanks for the info and the pictures. This is exactly what i'm trying do now, but decided to abandon well organizing and completely avoid of nesting whenever it possible because I see that it daramatically effects the RAM usage.
My decision effected by the fact that FS's biggest weakness is not the CPU usage but the RAM usage (when working with samples), so to avoid of pops, click, bad sounding multi-samples and random noises that come out from the project whenever a midi sequence is running in the background, the RAM usage must be reduced to the necessary minimum. Saw that the RAM usage threshold in FS apps is about 1gb RAM. whenever this limit is passed, the problems occur because 32bits RAM limitation chokes the project. I wonder if midi processes are effected by nesting as well;

How does FS generates midi processes? Does the midi signal actually recognized by FS as a combination of "green" orders? Because If so, nesting midi components would be a bad idea as well...