<html><head></head><body><div style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:13px;"><div id="ydp2011be50yahoo_quoted_3997065447" class="ydp2011be50yahoo_quoted">On Friday, April 6, 2018, 6:24:13 AM EDT, Giulio Moro via Pd-list <pd-list@lists.iem.at> wrote:
<div style="font-family:'Helvetica Neue', Helvetica, Arial, sans-serif;font-size:13px;color:#26282a;"><div><br></div>
<div><br></div>
<div><div dir="ltr">> I don't think it makes sense to have a malloc() and free() for each call to a msg box.<br clear="none">> Pd is already not very real-time friendly, why make it worse?<br clear="none">> There could be ...<br clear="none">> - statically allocated memory for t_gstack y in pd_pushsym</div><div dir="ltr"><br></div><div dir="ltr">But you can nest arbitrarily deep in patch loading, no?</div><div dir="ltr"><br></div><div dir="ltr">Also, patch loading time typically doesn't need to happen in realtime, as </div><div dir="ltr">you're also allocating memory for objects during that time plus probably </div><div dir="ltr">taking an i/o hit when loading abstractions.<br></div><div dir="ltr"><br></div><div dir="ltr">On the other hand, it would be interesting to use a memory pool like you </div><div dir="ltr">mention below and see its effect on load time. At least for the "canvas" field </div><div dir="ltr">of data structures in Purr Data I cache the binbuf so there's no i/o hit </div><div dir="ltr">there, only memory allocations.<br> </div><div dir="ltr"><br clear="none">> - 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?<br clear="none"></div><div dir="ltr"><br></div><div dir="ltr">I'd measure performance here first to determine the best course of action.</div><div dir="ltr">Even with a memory pool pd_pushsym is doing quite a few assignments. Pushing </div><div dir="ltr">and popping on every msg box method may get be noticeably different than </div><div dir="ltr">dereferencing a single cached value.</div><div dir="ltr"><br></div><div dir="ltr">Measuring [trigger] performance I could see differences depending on how </div><div dir="ltr">exactly the loop for the outlets was constructed.</div><div dir="ltr"><br></div><div dir="ltr">-Jonathan<br></div><div dir="ltr"><br clear="none">> Giulio<br clear="none"><br clear="none">On Thursday, 5 April 2018, 22:54:44 BST, Jonathan Wilkes via Pd-list <<a shape="rect" href="mailto:pd-list@lists.iem.at" rel="nofollow" target="_blank">pd-list@lists.iem.at</a>> wrote: <br clear="none"><br clear="none">> On Thursday, April 5, 2018, 3:20:03 PM EDT, Dan Wilcox <<a shape="rect" href="mailto:danomatika@gmail.com" rel="nofollow" target="_blank">danomatika@gmail.com</a>> wrote: <br clear="none"><br clear="none">> test? <a shape="rect" href="https://github.com/pure-data/pure-data/pull/346" rel="nofollow" target="_blank">https://github.com/pure-data/pure-data/pull/346</a><br clear="none"><br clear="none">That will add a malloc/free for every method call to a msg box. So <br clear="none">I'd measure the performance impact before using that <br clear="none">implementation.<br clear="none"><br clear="none">On the l2ork dev list I mentioned a potential way to cache the glist <br clear="none">in the t_messresponder to avoid allocation at message evaluation time. <br clear="none">But we haven't implemented that yet (nor measured the current <br clear="none">performance hit).<br clear="none"><br clear="none">-Jonathan<br clear="none"><br clear="none"><br clear="none"><br clear="none"><br clear="none"><br clear="none">--------<br clear="none">Dan Wilcox<br clear="none">@danomatika<br clear="none">danomatika.com<br clear="none">robotcowboy.com<br clear="none"><br clear="none"><br clear="none"><br clear="none"><br clear="none">_______________________________________________<br clear="none"><a shape="rect" href="mailto:Pd-list@lists.iem.at" rel="nofollow" target="_blank">Pd-list@lists.iem.at</a> mailing list<br clear="none">UNSUBSCRIBE and account-management -> <a shape="rect" href="https://lists.puredata.info/listinfo/pd-list" rel="nofollow" target="_blank">https://lists.puredata.info/listinfo/pd-list</a><div class="ydp2011be50yqt5107417577" id="ydp2011be50yqtfd20167"><br clear="none"><br clear="none"><br clear="none">_______________________________________________<br clear="none"><a shape="rect" href="mailto:Pd-list@lists.iem.at" rel="nofollow" target="_blank">Pd-list@lists.iem.at</a> mailing list<br clear="none">UNSUBSCRIBE and account-management -> <a shape="rect" href="https://lists.puredata.info/listinfo/pd-list" rel="nofollow" target="_blank">https://lists.puredata.info/listinfo/pd-list</a><br clear="none"><br clear="none">_______________________________________________<br clear="none"><a shape="rect" href="mailto:Pd-list@lists.iem.at" rel="nofollow" target="_blank">Pd-list@lists.iem.at</a> mailing list<br clear="none">UNSUBSCRIBE and account-management -> <a shape="rect" href="https://lists.puredata.info/listinfo/pd-list" rel="nofollow" target="_blank">https://lists.puredata.info/listinfo/pd-list</a><br clear="none"></div></div></div>
</div>
</div></div></body></html>