Difference in performance between "all in one patch" or "using subpatches"

ygreq's icon

Now related to my previous question regarding the speed comparison between using patch cords and send/receive pairs? (https://cycling74.com/forums/which-method-is-faster-patch-cords-or-sendreceive-pair), I was wondering if anyone of you know this one.

Which method is faster? All objects in one patch or using subpatches? Or to ask this in other words, does using subpaches (and also subpatches in subpatches) affect the speed of data transmission through patch cords?

I know that this could depend on how big a patch is, so I am expecting different answers, if there is a difference. :)

And maybe somebody knows the actual logic behind the different ways of patching (like Tom Swirly's answer on the other thread).

Thank you so much for any input!
ygreq

udo's icon

Hi ygreq,

Did you ever figure this out? I'm making a patch that uses the MaxScore object to create generative notation + generative combinations of sound files & some delay lines... I'm sure I'm doing things that are slowing down the patch, but I don't know what they are. It definitely could run faster. I wonder if you found a solution or have any tips...?

Thanks!
udo

broc's icon
Max Patch
Copy patch and select New From Clipboard in Max.

I did a little test to measure the overhead of subpatches.
On my system (2 GHz Intel C2D) it seems about 0.1 microseconds per data transmission.

Roman Thilenius's icon

the overhead of sending something using send as well as connecting to a subpatcher is minimal.

udo's icon

Ah, ok. Good to know. Thanks, broc & Roman. Do either of you have any advice on other general things I might do or check in my patch to ensure I'm not needlessly overusing the CPU?

Chris Muir's icon

While I'm a big fan of benchmarking this sort of stuff, I would like to caution about the trade offs between speed and clarity/maintainability. I would rather burn some CPU for the sake of clarity. Differences in algorithmic approaches are way more important than this sort of message sending overhead. Don't optimize too early, certainly not at the expense of maintainability.

Roman Thilenius's icon

you will find answers to this when you search the forum.

number one would be to get rid of all gui objects which are not needed to use the patch.

number two will be to rethink the whole thing, often there is a more clean and lean
solution to do the same. you will know what i mean when you look at your patches again
in two years.

udo's icon

Thanks to you both for the responses!
Udo