I'm assuming of course that no GUI objects in subpatches is optimal. but what sort of effect do sliders. toggles, bangs, etc have on CPU usage when hidden in unopened subpatches?
AFAIK none--if it is not visible, its gui calls are ignored.
From: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] On Behalf Of i go bananas Sent: Sunday, July 14, 2013 4:01 AM To: PD List Subject: [PD] CPU usage of GUI objects in subpatches
I'm assuming of course that no GUI objects in subpatches is optimal. but what sort of effect do sliders. toggles, bangs, etc have on CPU usage when hidden in unopened subpatches?
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]
Maybe this has changed now with the latest versions, so I would recommend to benchmark it again.
Ciao
Frank
On Sun, Jul 14, 2013 at 12:16:24PM -0400, Ivica Ico Bukvic wrote:
AFAIK none--if it is not visible, its gui calls are ignored.
From: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] On Behalf Of i go bananas Sent: Sunday, July 14, 2013 4:01 AM To: PD List Subject: [PD] CPU usage of GUI objects in subpatches
I'm assuming of course that no GUI objects in subpatches is optimal. but what sort of effect do sliders. toggles, bangs, etc have on CPU usage when hidden in unopened subpatches?
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Mapologies. What I mentioned was meant for pd-l2ork. Not sure about the others.
Best wishes,
Ico
-----Original Message----- From: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] On Behalf Of Frank Barknecht Sent: Monday, July 15, 2013 9:13 AM To: pd-list@iem.at Subject: Re: [PD] CPU usage of GUI objects in subpatches
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]
Maybe this has changed now with the latest versions, so I would recommend to benchmark it again.
Ciao
Frank
On Sun, Jul 14, 2013 at 12:16:24PM -0400, Ivica Ico Bukvic wrote:
AFAIK none--if it is not visible, its gui calls are ignored.
From: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] On Behalf
Of i
go bananas Sent: Sunday, July 14, 2013 4:01 AM To: PD List Subject: [PD] CPU usage of GUI objects in subpatches
I'm assuming of course that no GUI objects in subpatches is optimal. but what sort of effect do sliders. toggles, bangs, etc have on CPU usage
when
hidden in unopened subpatches?
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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
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
On 07/15/2013 05:40 PM, Miller Puckette wrote:
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 numberclosed 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
Getting back to the OP, I just want to point out that there are two separate issues at play here. I'll phrase them as a q&a:
Q: When inserting an iemgui for the patch author's convenience (or anyone else inspecting the abstraction), does it make a difference whether you put an iemgui in the main flow of the patch vs. outside of that flow (as Frank suggests)?
A: The answer is usually yes, _regardless_ of the cpu usage of the GUI object. It's always better to have one less object in the main object chain. If you just need to send values down the chain, add an iemgui as an additional input to the current object chain. If you want to see results of your patch in realtime, use the cord inspector which is available in both Pd-extended and Pd-l2ork.
There may be situations where you want to see a bunch of iemguis getting updated at once, but that's more likely to be a UI than something inside an abstraction.
Q: Are there times when it is useful to insert an iemgui into an object chain, say, inside an abstraction, aside from its usefulness as a GUI?
A: Yes-- see [tgl]. It takes the same [realtime] on my machine as
[f]---[== 0] when
the patch is not visible, plus you get visual feedback if you need it.
Of course if you
make the abstraction visible when you're sending a lot of data you'll
take a CPU usage
hit with [tgl] where you wouldn't for the non-GUI objects, but depending
on how you're
using it that may not be a factor.
-Jonathan
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
On 07/15/2013 08:16 PM, Jonathan Wilkes wrote:
On 07/15/2013 05:40 PM, Miller Puckette wrote:
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 numberclosed 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
Getting back to the OP, I just want to point out that there are two separate issues at play here. I'll phrase them as a q&a:
Q: When inserting an iemgui for the patch author's convenience (or anyone else inspecting the abstraction), does it make a difference whether you put an iemgui in the main flow of the patch vs. outside of that flow (as Frank suggests)?
A: The answer is usually yes, _regardless_ of the cpu usage of the GUI object. It's always better to have one less object in the main object chain. If you just need to send values down the chain, add an iemgui as an additional input to the current object chain. If you want to see results of your patch in realtime, use the cord inspector which is available in both Pd-extended and Pd-l2ork.
There may be situations where you want to see a bunch of iemguis getting updated at once, but that's more likely to be a UI than something inside an abstraction.
Q: Are there times when it is useful to insert an iemgui into an object chain, say, inside an abstraction, aside from its usefulness as a GUI?
A: Yes-- see [tgl]. It takes the same [realtime] on my machine as [f]---[== 0] when the patch is not visible,
I meant: [f]x[== 0]
-Jonathan
-
Frank Barknecht -
i go bananas -
Ivica Ico Bukvic -
Jonathan Wilkes -
Miller Puckette