[PD] CPU usage of GUI objects in subpatches

[Jonathan Wilkes]

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  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

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 at iem.at mailing list
>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list