[PD] suggestion: $0 in messages

Giulio Moro giuliomoro at yahoo.it
Fri Apr 6 15:21:44 CEST 2018


Yeah sorry I have no idea how deep these nest, I am not familiar with that part of the code.
In this case the memory could be allocated in the stack and then passed to something like   pd_pushsymnoalloc(t_pd *x, t_gstack* y) 
which should in turn skip the allocation. But yes, a cached value seems to make much more sense.

On the topic of pre-allocated memory pools, SuperCollider, for one, uses a pre-allocated pool https://github.com/supercollider/supercollider/blob/master/common/SC_AllocPool.cpp but it throws an exception upon failure instead of allocating more memory.

Best,
Giulio

On Friday, 6 April 2018, 13:42:26 BST, Jonathan Wilkes via Pd-list <pd-list at lists.iem.at> wrote: 
On Friday, April 6, 2018, 6:24:13 AM EDT, Giulio Moro via Pd-list <pd-list at lists.iem.at> wrote: 

> I don't think it makes sense to have a malloc() and free() for each call to a msg box.
> Pd is already not very real-time friendly, why make it worse?
> There could be ...
> - statically allocated memory for t_gstack y in pd_pushsym

But you can nest arbitrarily deep in patch loading, no?

Also, patch loading time typically doesn't need to happen in realtime, as 
you're also allocating memory for objects during that time plus probably 
taking an i/o hit when loading abstractions.

On the other hand, it would be interesting to use a memory pool like you 
mention below and see its effect on load time. At least for the "canvas" field 
of data structures in Purr Data I cache the binbuf so there's no i/o hit 
there, only memory allocations.


> - a pre-allocated memory pool meant for short-lived memory allocations to be used in real-time critical cases like this. If no memory available from the pool, only then allocate it (or allocate a new pool). There are probably other cases around the codebase where this would make sense, but why not starting with this?

I'd measure performance here first to determine the best course of action.
Even with a memory pool pd_pushsym is doing quite a few assignments. Pushing 
and popping on every msg box method may get be noticeably different than 
dereferencing a single cached value.

Measuring [trigger] performance I could see differences depending on how 
exactly the loop for the outlets was constructed.

-Jonathan


> Giulio

On Thursday, 5 April 2018, 22:54:44 BST, Jonathan Wilkes via Pd-list <pd-list at lists.iem.at> wrote: 

> On Thursday, April 5, 2018, 3:20:03 PM EDT, Dan Wilcox <danomatika at gmail.com> wrote: 

> test? https://github.com/pure-data/pure-data/pull/346

That will add a malloc/free for every method call to a msg box. So 
I'd measure the performance impact before using that 
implementation.

On the l2ork dev list I mentioned a potential way to cache the glist 
in the t_messresponder to avoid allocation at message evaluation time. 
But we haven't implemented that yet (nor measured the current 
performance hit).

-Jonathan





--------
Dan Wilcox
@danomatika
danomatika.com
robotcowboy.com




_______________________________________________
Pd-list at lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list



_______________________________________________
Pd-list at lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list

_______________________________________________
Pd-list at lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list


_______________________________________________
Pd-list at lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list



More information about the Pd-list mailing list