In terms of optimisation which is the best approach?

    Nov 14 2016 | 4:07 pm
    In terms of optimisation which is the best approach?
    Let´s say I have 10 message objects that are connected to 5 message objects (data and bang) making a total of 100 connection cords.
    Will it be more Memory and or CPU efficient if I use an extra message object as a hub (won't be visible) to connect the 10 message objects, then connecting the "hub" message object to the 5 message objects. This will give me the same result and it will use only 30 connection cords.
    In what concerns to the GUI I now it will be lighter for MAX to handle, but what about the internal coding for this? It will make any difference for the better?
    Thanks in advanced for you help!

    • Nov 15 2016 | 1:32 am
      Design first, performance optimization only if necessary. Here, adding a message box, even hidden, will be "less" performant, but in most cases you won't notice it. Anyway, isn't there a way for you to have just a [number] object going to [prepend a], [prepend b] etc.?
    • Nov 15 2016 | 9:50 am
      what jfc said.
      i´d use a [t l] (or a subpatch with one inlet connect to one outlet) and catch all ten, then connect it to the 5 objects next in line, just for convienience, because it is less connections and easier to repatch if a change of the code is required.
      a trigger - and even an empty subpatcher - will require 2 or so CPU cycles, but that can be disregarded unless your computer still has a nubus slot.
    • Nov 15 2016 | 11:21 am
      Hi guys, thanks a lot for your input!
      Jean, I agree that a [prepend] will use half the connections. This example (screenshot one) who has exaggerated cording (the same can be achieved with a "a b c d e" on a [message], [zl.nth], and an [uzi], using just a couple of cords ) is jut to focus on the impact cords's amount can have on patch's memory usage/loading time vs CPU usage. I didn't know how cords usage impact on those variables but I'm starting to figure it out.
      Roman, the concept on using an empty patch as a HUB for cords seems to be pretty interesting, I will try it on my upcoming benchmarks, thanks!
      Btw, I did some test with those examples and I found that excessive usage of cords has a considerable impact on what concerns to memory usage and patch loading time. Making a patch recursive, lowering the number of cords, etc. has a small increment on CPU usage, something that can be disregarded on the practice as Roman said, also memory usage and patch loading time got really improved (ymmv), so I will have this in mind for my future patching.
      Thanks again guys for taking your time to write your thoughts here, Best!
    • Nov 15 2016 | 1:31 pm
      i´ ve started using subpatchers when i wanted more than one output and have a certain order of execution - in opposite to [trigger], inlet/outlet will transport _any kind of message.
    • Nov 15 2016 | 1:34 pm
      oh thats right: load times are actually a problem if you drive that concept too far (same with poly patchers). but from a "design vs CPU" perspective it is perfectly ok.
      i do it in-patcher btw.
      the empty one is [p t], but you can also make stuff like [p t b] which already has a [t b] inside for the second outlet.
    • Nov 15 2016 | 2:27 pm
      Roman: "inlet/outlet will transport _any kind of message."
      This is a good thing to remember!
      I'll take al your notes in mind, thanks!