The second lazy-load option might work pretty well, but what would the 
per-instance/threading considerations be?

> On Apr 6, 2018, at 12:21 PM, Giulio Moro <giuliom...@yahoo.it> 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
> - 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?
> 
> Giulio
> 
> On Thursday, 5 April 2018, 22:54:44 BST, Jonathan Wilkes via Pd-list 
> <pd-list@lists.iem.at> wrote: 
> 
>> On Thursday, April 5, 2018, 3:20:03 PM EDT, Dan Wilcox 
>> <danomat...@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 <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>



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

Reply via email to