[PD] abstraction penalty benchmarks
Jonathan Wilkes
jancsika at yahoo.com
Fri Aug 9 04:46:24 CEST 2013
On 08/08/2013 04:57 PM, Claude Heiland-Allen wrote:
> Hi,
>
> Today I remembered one performance where I saved an abstraction with
> many instances, bringing things to a halt. So I benchmarked this
> scenario and some similar ones - some seem to scale very badly.
>
> pure-data.git gcc-4.8.1 GNU/Linux/Debian/Wheezy amd64 64bit
> Pd-0.45.0 ("test") compiled 17:10:02 Aug 8 2013
>
> m n open dsp save close
> 3 512 38.503 1.33879 44.26 3.985
> 4 4096 324.507 10.7379 786.227 150.602
> 5 32768 2611.92 85.405 79234.2 35853
>
> key description
> m number of levels of nested abstractions
> n total number of instances at deepest level
> open time to load patch
> dsp time to toggle dsp on then off (1000 runs averaged)
> save time to save one instance at deepest level
> close time to close patch
>
> all times are in ms, measured with [realtime]
> rows run sequentially in their own pd instance
> dsp was off at the start of each test
> the whole run is in zero logical time
> cpu frequency scaling was disabled (for real)
> pd was run with -nogui -nosound -nrt
>
> 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.
>
> See attached tarball if you want to try it yourself.
Thanks for the stats.
Any idea why "save" is so much greater than close + open?
Also, any idea what pd is doing for the bulk of that time when
saving, closing, opening, and dsp'ing?
-Jonathan
>
>
> Claude
>
>
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20130808/788bc0a9/attachment.htm>
More information about the Pd-list
mailing list