[PD] Understanding the mechanics of rebuilding Pd's DSP graph

[Roman Haefeli]

On Sun, 2015-09-20 at 22:19 +0200, IOhannes m zmölnig wrote:
> On 09/17/2015 11:55 PM, Roman Haefeli wrote:
> 
> > Is the time it takes to recalculate the graph only dependent on the
> > number of tilde-objects running in the current instance of Pd? If so, is
> > that a linear correlation? 10 times more tilde-objects means it takes 10
> > times as long to recalculate the graph?
> 
> [skipping those]

Simple tests suggests that the relation is linear. But maybe this
depends on the kind of graph? What I tested: I created 500 audio
processing abstractions dynamically and then I measured the time it
takes to send 'dsp 0, dsp 1' to pd. I did the same test again with 1000
instances and time doubled.

> > Why is resizing tables so much slower, when tilde-objects are
> > referencing it? I noticed that even resizing very small tables can be a
> > cause for audio drop-outs. I wonder whether 'live-resizing' should be
> > avoided altogether.
> 
> because the table-accessing objects will only check whether a table
> exists and of what size it is) when the DSP graph is re-calculated.
> this is a speed optimization, so those objects don't need to check the
> table existance/size in each signal block.
> the way how it is implemented is, that a table is marked as "being used
> in DSP processing" by a referencing object. as soon as such a table
> changes it's size (or is deleted), the DSP graph is notified - by means
> of recalculation.

Now, after knowing all these facts, it seems unwise to do table resizing
at all, especially for quite small tables. With today's amounts of RAM
available, it seems wise to allocate enough at patch-loading time and
only utilize the necessary part of it.  

> i guess the API could be changed to *unuse* a table (a simple refcounter
> should do), so that as soon as no DSP-object is referencing the object
> within the DSP-graph, any substantial change to it wouldn't trigger a
> DSP  graph recompilation.

The ability to recompile only a partition of the graph in general would
be a huge gain, IMHO. The ability to resize arrays without recompilation
isn't that big an advantage, is it? It would allow for a little simpler
patching, though.

Roman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150922/e8575728/attachment.sig>