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 danomatika.com robotcowboy.com _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list