gbravetti

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?

https://www.dropbox.com/s/fpcjyzbrfa59j0m/Screenshot%202016-11-14%2009.36.53.png?dl=0

An screenshot of the example above: https://www.dropbox.com/s/fpcjyzbrfa59j0m/Screenshot%202016-11-14%2009.36.53.png?dl=0


in-terms-of-optimisation-which-is-the-best-approach

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.?

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.

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,

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.

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!


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.

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.

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.

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.

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.


Roman: "inlet/outlet will transport _any kind of message."

I'll take al your notes in mind, thanks!
