[PD] abstraction penalty benchmarks
Claude Heiland-Allen
claude at mathr.co.uk
Fri Aug 9 16:15:52 CEST 2013
Hi,
On 09/08/13 04:27, Miller Puckette wrote:
> Here's a guess - I think each copy of the abstraction binds itself to
> a symbol, "pd-<name>". Binding is fast bt unbinding is linear-time in the
> number of things bound to the symbol... ouch.
Yes, I think that's it:
git master from yesterday
Pd-0.45.0 ("test") compiled 17:10:02 Aug 8 2013
patch bench open dsp save close
small 4.6e-05 38.775 1.34085 44.326 4.012
medium 5.2e-05 314.812 10.2582 715.956 144.512
large 4.7e-05 2639.28 85.3561 78711.5 35918
git master, lightly patched with the attached
Pd-0.45.0 ("test") compiled 14:36:39 Aug 9 2013
patch bench open dsp save close
small 4.3e-05 36.167 1.31707 39.657 3.447
medium 4.4e-05 291.52 9.8958 327.389 18.067
large 4.3e-05 2443.07 82.0808 3628.66 224.972
> There's a good reason to bind toplevels and named sub-patches to ther names,
> but I think there's little reason to do it for abstractions - perhaps I can
> take this out, but I'd have to leave it as an option for compatibility (ouch!)
The attached patch doesn't do this, but it should be easy to add a
global compatibility flag to the new canvas_should_bind() function.
Toplevel patches are still bound to pd-<name>.pd and subpatches [pd
<name>] are still bound to pd-<name>; it's just abstraction instances
that no longer have the automatic binding.
> On Thu, Aug 08, 2013 at 10:46:24PM -0400, Jonathan Wilkes wrote:
>> On 08/08/2013 04:57 PM, Claude Heiland-Allen wrote:
[snip]
>>> The killer in the bottom right corner: with 8x as many abstractions, it
>>> takes 100x as long to save an instance, and 200x as long to close the patch.
[snip]
>> Any idea why "save" is so much greater than close + open?
I think Miller had the answer.
>> Also, any idea what pd is doing for the bulk of that time when
I haven't profiled yet (I had trouble even getting debug symbols into an
installed Pd with the autoconf system, no success yet..), so the
following are just guesses:
>> saving
searching for copies of the abstraction to reload, then reloading them
via some select/cut/undo method (which preserves connections). also
unbinding symbols...
>> closing
calling all the destructors. also unbinding symbols...
>> opening
refinding/reloading/reparsing/reinstantiating all the abstractions (I
need to relocate my abstraction cache patches and update them to current Pd)
>> dsp'ing?
traversing each canvas to topologically sort its dsp objects and build
the dsp chain - which gets resizebytes() each time something is added,
could make it O(log(N)) count of resizes (doubling the size each time)
but I tried it and it saved about 9 microseconds, not worth the extra
complexity...
Claude
--
http://mathr.co.uk
More information about the Pd-list
mailing list