<html><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px"><div id="yui_3_16_0_1_1442945158104_8146">In C, what's the overhead of having function_call(return array->x_size) instead</div><div id="yui_3_16_0_1_1442945158104_8146">of array->x_size inside a perform routine?</div><div id="yui_3_16_0_1_1442945158104_7875"><br></div><div id="yui_3_16_0_1_1442945158104_7875" dir="ltr">If that's not significant, it seems like it'd be better to over-allocate the array at creation/resize time and report the requested size to the user. That way reallocation (and dsp-rebuilding) is only necessary if there's a substantial size change, or if the array is used by an external that uses the old API.</div><div id="yui_3_16_0_1_1442945158104_7875" dir="ltr"><br></div><div id="yui_3_16_0_1_1442945158104_7875" dir="ltr">That's certainly more difficult to do than just rebuilding the graph on every resizing. But to me it's preferable to telling new users, "Here's how</div><div id="yui_3_16_0_1_1442945158104_7875" dir="ltr">to resize an array, which is a central feature for using objects like [tabplay~] and</div><div id="yui_3_16_0_1_1442945158104_7875" dir="ltr">'Put' menu arrays and [soundfiler], but in reality don't use it because</div><div id="yui_3_16_0_1_1442945158104_7875" dir="ltr">[[explanation of Pd's implementation details go here]]."</div><div id="yui_3_16_0_1_1442945158104_7875" dir="ltr"><br></div><div id="yui_3_16_0_1_1442945158104_7875" dir="ltr">-Jonathan</div><div class=".yiv1406990379yahoo_quoted"> <div style="font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px;"> <div style="font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px;"> <div class="qtdSeparateBR"><br><br></div><div class="yiv1406990379yqt6231665067" id="yiv1406990379yqtfd21706"><div dir="ltr"> <font size="2" face="Arial"> On Tuesday, September 22, 2015 12:05 PM, Roman Haefeli <reduzent@gmail.com> wrote:<br clear="none"> </font> </div> <br clear="none"><br clear="none"> <div class="yiv1406990379y_msg_container">On Sun, 2015-09-20 at 22:19 +0200, IOhannes m zmölnig wrote:<br clear="none">> On 09/17/2015 11:55 PM, Roman Haefeli wrote:<br clear="none">> <br clear="none">> > Is the time it takes to recalculate the graph only dependent on the<br clear="none">> > number of tilde-objects running in the current instance of Pd? If so, is<br clear="none">> > that a linear correlation? 10 times more tilde-objects means it takes 10<br clear="none">> > times as long to recalculate the graph?<br clear="none">> <br clear="none">> [skipping those]<br clear="none"><br clear="none">Simple tests suggests that the relation is linear. But maybe this<br clear="none">depends on the kind of graph? What I tested: I created 500 audio<br clear="none">processing abstractions dynamically and then I measured the time it<br clear="none">takes to send 'dsp 0, dsp 1' to pd. I did the same test again with 1000<br clear="none">instances and time doubled.<br clear="none"><br clear="none">> > Why is resizing tables so much slower, when tilde-objects are<br clear="none">> > referencing it? I noticed that even resizing very small tables can be a<br clear="none">> > cause for audio drop-outs. I wonder whether 'live-resizing' should be<br clear="none">> > avoided altogether.<br clear="none">> <br clear="none">> because the table-accessing objects will only check whether a table<br clear="none">> exists and of what size it is) when the DSP graph is re-calculated.<br clear="none">> this is a speed optimization, so those objects don't need to check the<br clear="none">> table existance/size in each signal block.<br clear="none">> the way how it is implemented is, that a table is marked as "being used<br clear="none">> in DSP processing" by a referencing object. as soon as such a table<br clear="none">> changes it's size (or is deleted), the DSP graph is notified - by means<br clear="none">> of recalculation.<br clear="none"><br clear="none">Now, after knowing all these facts, it seems unwise to do table resizing<br clear="none">at all, especially for quite small tables. With today's amounts of RAM<br clear="none">available, it seems wise to allocate enough at patch-loading time and<br clear="none">only utilize the necessary part of it. <br clear="none"><br clear="none">> i guess the API could be changed to *unuse* a table (a simple refcounter<br clear="none">> should do), so that as soon as no DSP-object is referencing the object<br clear="none">> within the DSP-graph, any substantial change to it wouldn't trigger a<br clear="none">> DSP graph recompilation.<br clear="none"><br clear="none">The ability to recompile only a partition of the graph in general would<br clear="none">be a huge gain, IMHO. The ability to resize arrays without recompilation<br clear="none">isn't that big an advantage, is it? It would allow for a little simpler<br clear="none">patching, though.<div class="yiv1406990379yqt4455421800" id="yiv1406990379yqtfd79300"><br clear="none"><br clear="none">Roman</div><br clear="none"><div class="yiv1406990379yqt4455421800" id="yiv1406990379yqtfd99944">_______________________________________________<br clear="none"><a rel="nofollow" shape="rect" ymailto="mailto:Pd-list@lists.iem.at" target="_blank" href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br clear="none">UNSUBSCRIBE and account-management -> <a rel="nofollow" shape="rect" target="_blank" href="http://lists.puredata.info/listinfo/pd-list">http://lists.puredata.info/listinfo/pd-list</a><br clear="none"></div><br clear="none"><br clear="none"></div> </div></div><div class="yiv1406990379yqt6231665067" id="yiv1406990379yqtfd75181"> </div></div><div class="yiv1406990379yqt6231665067" id="yiv1406990379yqtfd18884"> </div></div></div></body></html>