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

    ygreq
    Jul 10 2011 | 11:48 am
    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
      Oct 08 2011 | 4:25 am
      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
      Oct 08 2011 | 10:32 am
      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
      Oct 08 2011 | 12:30 pm
      the overhead of sending something using send as well as connecting to a subpatcher is minimal.
    • udo
      Oct 08 2011 | 1:52 pm
      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
      Oct 08 2011 | 5:13 pm
      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
      Oct 08 2011 | 5:24 pm
      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
      Oct 08 2011 | 6:14 pm
      Thanks to you both for the responses! Udo