[PD] abstraction penalty benchmarks

[Miller Puckette]

Well, if ia user really wants 32K receives of the same name, (s)he can have
them - but most people won't want to do that.  In contrast, you can't have
32K copies of an abstraction without hitting this problem - and the business
of binding patches to names is only rarely actually used.  So (I'm now thinking)
Pd should make it easy to defeat that useless behavior.

cheers
M
On Fri, Aug 09, 2013 at 07:11:02PM -0400, Jonathan Wilkes wrote:
> On 08/09/2013 04:31 PM, Miller Puckette wrote:
> >Or... just limit the number of canvases that can bind themselves to a single
> >symbol to a reasonable number (5 or so, settable by flag for back-compatibility
> >if anyone cares).
> 
> What happens to Claude's test if you a) patch Pd to stop binding
> pd-abstractionName.pd, and b) put a [receive pd-abstractionName.pd]
> inside the abstraction that's getting massively replicated?
> 
> I'd hypothesize that you end up with the same or closely similar problem,
> no?
> 
> If so then messing with the abstraction name binding risks introducing
> bugs or breaking some strange but interesting patches, and doesn't
> solve the larger problem which becomes anxiety about [s]/[r] pairs or
> any other nonlocal connection objects inside abstractions.
> 
> -Jonathan
> 
> >
> >cheers
> >M
> >
> >On Fri, Aug 09, 2013 at 07:51:30PM +0100, Claude Heiland-Allen wrote:
> >>On 09/08/13 19:42, Miller Puckette wrote:
> >>>There still could be situations where an abstraction has a sub-patch ("pd foo"
> >>>for instance) - I'm not clear as to whether those namings should be supressed
> >>>as well.  It seems like a tricky problem - lots of people seem to use
> >>>abstractions with only one instance and might be depending on the bindings.
> >>Maybe the best fix would be to make pd_unbind() constant time (perhaps
> >>by storing bindings in a doubly-linked list instead of a singly-linked
> >>list) and be done with it, instead of hacking workarounds..
> >>
> >>
> >>Claude
> >>-- 
> >>http://mathr.co.uk
> >>
> >>
> >>_______________________________________________
> >>Pd-list at iem.at mailing list
> >>UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
> >_______________________________________________
> >Pd-list at iem.at mailing list
> >UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
> 
> 
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list