I tried this with four versions of a subpatch, one with "nothing" (just an inlet connected through to an outlet), one with a "float", one with hslider, and one with a number box (not "number2", just control-3 number). Subtracting out the control case, I sent 1000000 random numbers through and asked the cputime object how much time elapsed, and got approximately:
float hsl number
closed 10 50 150 open 10 50 150
This was usin "until" to loop 1000000times. Trying the same thing with "metro 0.001" gives:
closed <10 50 150 open <10 60 200
That wasn't at all what I was expecting to see!
This was on a core 2 duo 7600 running at 1.6 GHz (my patch wasn't CPU hungry enough to make my CPU want to speed up), linux 3.6.3-1.fc17.x86_64 (Fedora)
cheers Miller
On Mon, Jul 15, 2013 at 05:18:00PM -0400, Jonathan Wilkes wrote:
On 07/15/2013 09:13 AM, Frank Barknecht wrote:
Hi,
I didn't test current Pd versions nor your fork, but up to 0.43 GUI objects in subpatches or abstractions were a substantial and significant CPU load when they are activated, even when invisible. So this is slow:
[r data] | [hsl ...] | [s data-out]
But this is fast:
[r data] | | [hsl ...] |/ [s data-out]
Pd-l2ork version 20130528:
I put a [inlet]---[hsl]---[outlet] in a subpatch and compared to a subpatch with [inlet]--[float]--[outlet].
Measuring sending a random float to each subpatch. Hsl subpatch was between 0.005 and 0.006 and float subpatch was 0.004.
Measuring cpu usage with gnome-system-monitor with a [metro 1] driving the hsl subpatch:
- when subpatch is un-vis'd and metro is off, cpu usage is around 15%
- when subpatch is un-vis'd and metro is on, cpu usage is between
15-20% (using gnome-system-monitor so it's hard to discern the difference on the graph)
- when subpatch is vis'd, cpu usage is around 60%
So when the patch is vis'd, substantial and significant CPU load. When unvis'd, not so much.
Debian wheezy, AMD64, pd-l2ork
-Jonathan
Maybe this has changed now with the latest versions, so I would recommend to benchmark it again.
Ciao
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list