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 > <email@example.com> 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/>
_______________________________________________ Pdfirstname.lastname@example.org mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list