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-boun...@iem.at [mailto:pd-list-boun...@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
Re: [PD] CPU usage of GUI objects in subpatches
Mapologies. What I mentioned was meant for pd-l2ork. Not sure about the others. Best wishes, Ico -Original Message- From: pd-list-boun...@iem.at [mailto:pd-list-boun...@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-boun...@iem.at [mailto:pd-list-boun...@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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] CPU usage of GUI objects in subpatches
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
Re: [PD] CPU usage of GUI objects in subpatches
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 100 random numbers through and asked the cputime object how much time elapsed, and got approximately: float hsl number closed 1050 150 open1050 150 This was usin until to loop 100times. 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] CPU usage of GUI objects in subpatches
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 100 random numbers through and asked the cputime object how much time elapsed, and got approximately: float hsl number closed 1050 150 open1050 150 This was usin until to loop 100times. 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 qa: 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] CPU usage of GUI objects in subpatches
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 100 random numbers through and asked the cputime object how much time elapsed, and got approximately: float hsl number closed 1050 150 open1050 150 This was usin until to loop 100times. 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 qa: 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] CPU usage of GUI objects in subpatches
AFAIK none--if it is not visible, its gui calls are ignored. From: pd-list-boun...@iem.at [mailto:pd-list-boun...@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
