When building a patch with numerous elements in different windows, is it possible to say which is less taxing on the processor: abstractions or subpatches?

I believe that in terms of cpu usage there's no difference. All objects, messages,... need to be created anyway, and there's no difference between objects residing in abstractions or subpatches. The difference between the two has more to do with a codingstyle. I know that many people around here like abstractions because they're ready to be reused in all of your patches. The problem i've had with them is that abstractions define a contract. Once you use them, you can not change their interfaces (that is the inlets/outlets) anymore because then you will break your patches. That's why i personally like subpatches more. They can naturally evolve and when you need it for another patch you can just copy them. But it's all a matter of personal taste/workflow of course...

yeah, i don't think it matters too much, or even at all, for processing speed.

but when loading a patch, it may be faster to load subpatches, i think. because, every time you load an abstraction, pd has to find where that abstraction lives, and then load it.

Cool. Thanks.

i think pd only checks to see where the abstraction lives the first time you load it - but that might just be for externs

since the following took me a while to come across and has improved my workflow a lot, it might be worth mentioning.

the advantage of abstractions to subpatches is the dynamic naming. this is very handy, if the same patch will be used over and over again, yet contains receives and send, that correspond to different gui controls.

from start:
when you create the abstractionpatch, name all the communictian within with a prefix of $1-andthenthemessage.
this is for messages, that receive something from the outside the abstraction, or that send to outside the abstraction.
save a patch to become an abstraction, load it into the rootpatch with
[nameoftheabstraction someidentifier]
"someidentifier" can be just anything, just some name. ... i'll name it xy1

now, if you open the abstraction, you see a "nameoftheabstraction.pd (xy1)" in the titlebar of the abstraction-patcher.

let's say you have a object inside the abstraction, waiting for numbers, you might call it [r $1-gimmenumbers]

if you now want to send to something in the abstraction, lets say from a slider, the send-field needs to be named with "xy1-gimmenumbers"

basically, what this does, is substitute the identifier for the $1 in the abstraction.

so if you have two abstractions, that are always supposed to do exactly the same, yet process individually, copy the first one and i.e. name it xy2.

all controls with the prefix xy2- will send to that abstraction.

plus, if you edit something in the abstraction, it obviously changes whereever you used that abstraction.
normal subpatches are fully independent and need to be manually edited.

You can also avoid having to send your abstractions arguments by using $0 instead of $1, $2, $3, etc. Instead of being filled by an argument, $0 is given a number that is unique to that instance of a patch or abstraction. Of course, this really is only useful for [send] and [receive] pairs within the abstraction. If you want to communicate with them from outside it, you'll probably want to go the $1 route.

If you're at all familiar with the concept of Object Oriented Programming, specifically Encapsulation, you can think of $0 as private attributes and $1,$2... as public ones.

Private means anything that only the abstraction knows about and deals with. Public would be attributes that can be accessed from outside the abstraction.

You have to be careful with public attributes since those amount to a contract (like domien said). You have to make sure that any changes to them are backwards compatible or you might break any patch that uses the abstraction.

Note that inlets and outlets would also be public.

subpatches seem to allow more room on the current patch by extending it

abstractions are more like object classes you can reuse and duplicate

God lecture: https://cycling74.com/2007/02/05/managing-complex-patches-in-max/#.VuHAi8eJ-zK