Has anyone noticed some nasty performance issues over time running patches with number boxes and GOP?
Number boxes seem to affect performance proportionately to how many times they've changed. Leaving a patch open that has multiple number boxes that change a few times every second (for example bars:beats:ticks timer) for an hour or more can sometimes bring my system to a grinding halt. Restarting PD and reloading the patch usually fixes it.
This seems to exacerbated if the number boxes are within a GOP canvas, and even more so if said GOP canvas is contained in another GOP canvas (for example, a GOP VU inside a GOP preamp).
My immediate guess is that the number box code is doing dynamic memory allocation, and fragmenting memory over time. Is this a PD thing or a tcl/tk thing?
Damian Stewart a écrit :
Has anyone noticed some nasty performance issues over time running patches with number boxes and GOP?
More widgets are used, more performances will decrease, the design of a patch could be an interesting topic...
Number boxes seem to affect performance proportionately to how many times they've changed Leaving a patch open that has multiple number boxes that change a few times every second (for example bars:beats:ticks timer) for an hour or more can sometimes bring my system to a grinding halt. Restarting PD and reloading the patch usually fixes it.
We don't need to put a numberbox for each value for sighing a changing set of value, canvas could be used as well. one numberbox could be used with some patch magick, I particulary use the zexy object [demux] for for using a single numbox to set a large bunch of parameters.
This seems to exacerbated if the number boxes are within a GOP canvas, and even more so if said GOP canvas is contained in another GOP canvas (for example, a GOP VU inside a GOP preamp).
VU is dramatically a performance issue, but they could be replaced by lighter objects, like canvas and sliders.
___________________________________________________________________________ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com
Patco wrote:
Damian Stewart a écrit :
Has anyone noticed some nasty performance issues over time running patches with number boxes and GOP?
More widgets are used, more performances will decrease, the design of a patch could be an interesting topic...
Sure, but I'm not talking about more widgets => slower speed, I'm talking about some widgets + time => slower speed. In other words, the widgets seem to be slowing down over time. If this is the case, then this is what we in software development might call a Bad Thing.
VU is dramatically a performance issue, but they could be replaced by lighter objects, like canvas and sliders.
Yeah, maybe VU was a bad example. This is true of numbers as well - and surely displaying a number is a simpler task than displaying a slider?
On Jan 27, 2007, at 2:12 AM, Patco wrote:
Damian Stewart a écrit :
Has anyone noticed some nasty performance issues over time running
patches with number boxes and GOP?More widgets are used, more performances will decrease, the design
of a patch could be an interesting topic...Number boxes seem to affect performance proportionately to how
many times they've changed Leaving a patch open that has multiple number boxes that change a
few times every second (for example bars:beats:ticks timer) for an
hour or more can sometimes bring my system to a grinding halt.
Restarting PD and reloading the patch usually fixes it.We don't need to put a numberbox for each value for sighing a
changing set of value, canvas could be used as well. one numberbox could be used with some patch magick, I particulary
use the zexy object [demux] for for using a single numbox to set a
large bunch of parameters.This seems to exacerbated if the number boxes are within a GOP
canvas, and even more so if said GOP canvas is contained in
another GOP canvas (for example, a GOP VU inside a GOP preamp).VU is dramatically a performance issue, but they could be replaced
by lighter objects, like canvas and sliders.
A quick fix is to use a [mapping/resample 100], which will just
output every 100ms. You probably can't read numbers faster than
every 100ms, and that will reduce the amount a redraws a lot. AFAIK,
the GUI objects try to draw everything they receive, even if it's
every 1ms. Almost all screens refresh every 10-17ms (60-100Hz), so
it's useless to update the number box anymore than that.
IMHO opinion, this should be built into the GUI objects. They should
only update at most every 10ms, or maybe it would be possible to get
the screen refresh rate via Tcl/Tk and set it according to that.
.hc
______________________________________________________________________ _____ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo!
Mail et son interface révolutionnaire. http://fr.mail.yahoo.com
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
¡El pueblo unido jamás será vencido!
-
Damian Stewart -
Hans-Christoph Steiner -
Patco