[PD] variable receive objects?

[Miller Puckette]

[snip]
> >>>Also, there are declarations after functional lines, e.g.,
> >>>
> >>>+	change_bindlist_via_graph = 1;
> >>>      t_bindelem *e;
> >>>
> >>>which is not standard C - something I frequently have to clean up in
> >>people's
> >>>patches :)
> >>You mean declaration of a global variable needs to be placed at the top of
> >>the source file? Sure, that is an easy fix. It's been placed here in
> >>proximity to make the patch more legible.
> >>
> >It's an automatic variable whose declaration should be at the beginning of a
> >block.  Otherwise Visual C++ seems to get offended (and I don't find out
> >until I crank up my stupid windows machine :)
> 
> But it is declared as a global variable at the beginning of the diff
> so it is not an automatic variable that is destroyed after function
> exits:
> 
> +static int change_bindlist_via_graph = 0;
> +
> +static void bindlist_cleanup(t_bindlist *x)
> 
> Are you saying that I need to re-declare it within the function? If
> so, that is the first time I would've seen anything like it and it
> is something certainly the rest of the Pd code does not conform to,
> either (or at least pd-extended).
> 
I'm just saying that the automatic varable t_bindelem *e should be declared
at the beginning of the block - no worries about change_bindlist_via_graph.

> >
> >>>I think something like what you proposed could work; there would still be
> >>a
> >>>performance hit which I'd probably want to measure before committing to
> >>>doing this... since after all we're just talking about a wierd and
> >>obnoxious
> >>>'feature'
> >>>in IEMGUIs that I would simply take out if I could :)
> >>I am not so sure there is a performance hit since in both cases
> >>dereferencing happens in exactly the same way, except in this one the
> >>referencing is delayed and in the interim structs destined to be
> >>dereferenced are made to point to null and then skipped if a subsequent call
> >>trips over a null-pointing struct before it has been dereferenced. As such
> >>its performance impact should be minimal.
> >>
> >Main performance hit would be that every time anyone traverses a bindlist
> >(many send/receive messages, perhaps most) there's all that extra code in
> >bindlist_bang(), etc. needed to make the extra tests (possible zero receiver
> >and possible cleanup needed afterward).
> Clean-up afterward is already implemented and is done within
> bindlist_cleanup() call which is nearly identical in terms of its
> workload to what was originally placed within pd_unbind, so I
> seriously doubt this will make much if any difference.
> 
> What will potentially add a bit of an overhead is the call above
> that I forgot to add:
> 
> if (e->e_who != NULL) pd_whatever(e->e_who);
> 
> I honestly have no idea how much a single if statement checking for
> a null pointer requires in terms of CPU usage. That said, FWIW I
> seriously doubt that this one if would cause that much of cpu
> overhead even if executed on a large number of calls.
> >
I think bindlist_bang() etc are more critical than pd_unbind as they naturally
get called many times while a patch is running whereas pd_unbind is typically
called only when objects are deleted.  So moving checks from pd_unbind()
to  bindlist_bang() etc decreases pd's run-time efficiency.

cheers
M