I would like to have just one cable going through my patch, from which I can access all relevant data. Are there performance aspects to consider when building classes or is this mostly for human readability and flexibility? For example, if I build an UBER class for my patch which holds the child classes for textures, layers, video streams, etc…
Will this cost more performance to read and write elements to sub classes somewhere within the patch or is this neglectible?
Also, does it matter how many values a method within a class retrieves?
For example, if I have a large object. Is it more performant to have different methods which provide specific data (get A, get AB, get C) or is it the same to have one (split ABC) and use that everywhere? Does the compiler take care of that, or does the “split” unnecessarily retrieve all data, even if I don’t use it?
Again, this question is not about readability, just performance.
I believe that apart from performance (which is a question for the devs) there is also the flexibility to consider in developing a system. If it is already large and you want to continue developing it then making one big class would definitely be against the S.O.L.I.D. principles. Mostly the first one in that particular case.
Single Responsibility Principle (SRP)
Open Closed Principle (OCP)
Liskov Substitution Principle (LSP)
Interface Segregation Principle (ISP)
Dependency Inversion Principle (DIP)
For example suppose you get data from the same class everywhere then if you modify something in it you will have to go through also everywhere it is used.
Instead you would gain a lot breaking it in smaller part and use Interface. In the end there will always be some kind of parent class or node in general that would hold everything.
You shouldn’t see any performance difference. Using a class to pass information from A to B could only become problematic if it happens a lot (thousands of time per frame) and each time a new instance of that class would be created leading to a lot of memory allocations on the heap. But from your description it’s not about that at all, instead it seems you have one instance of your UBER class you pass to your “high-level” nodes. That’s perfectly fine, we did a project in the past like that as well.
Split vs Get - there’s no magic applied by the compiler. I could imagine that small split operations could get inlined by the JIT compiler and not needed branches eliminated. However that would only happen if you export your patch. While running in the editor this is less likely to happen because we use virtual calls in classes to support changing the running program.
But again, as long as we’re not talking about an access count in the thousands per frame don’t think about it. Even though the timings on the tooltip might show you a few µs - the overhead of that benchmarking code is much much higher than the split operation itself.
