I was under the impression that starting pd without the gui would take out some of the slow downs assoicated with the gui such as gui object generation. I have some objects in my rc-patches that build the object based on its creation args such as [rc-seq 16 4] makes 16 toggle boxes with 4 beat divisions. Now if I have a bunch of these it slows down the loading of my patch considerably, which I understand ... but it also slows down loading in -nogui mode which I don't. So is -nogui mode doing all of the tk work but just not drawing the window?
The main problem is this makes patch loading realllyyy slow on my performance computer, PIII 500. So I'm going to actually rebuild all of the songs using static objects instead of dynamic ones ... which is too bad because the flexibility of the dynamic objects was nice when creating the song initially. So is that my only option for now, or is there some super trick I haven't noticed?
On Mon, 2007-12-17 at 01:15 +0100, Daniel Wilcox wrote:
I was under the impression that starting pd without the gui would take out some of the slow downs
afaik, this is only half true. please someone correct me, if i am wrong, but i think, only the gui drawing of the windows, that are actually displayed on screen (this includes also minimized windows), uses additional cpu power. if your main patch shows only [pd allyourstuff] box, then almost nothing has to be drawn.
assoicated with the gui such as gui object generation. I have some objects in my rc-patches that build the object based on its creation args such as [rc-seq 16 4] makes 16 toggle boxes with 4 beat divisions. Now if I have a bunch of these it slows down the loading of my patch considerably, which I understand ... but it also slows down loading in -nogui mode which I don't. So is -nogui mode doing all of the tk work but just not drawing the window?
no. as i said before, probably not so much is used for tk. so you gain
not that much by starting pd with -nogui. i'd say most of the cpu time
on patch load is useed for generating all the dynamic objects, which
also includes recompiling of the dsp-graph, which is - again: correct
me, if this is wrong - done on every instantiation of an (~-?) object.
if this is true, the cpu time is increased exponentially (or at least
progressively of some kind) with every new object, that needs to be
instantiated. at least that is what i experienced myself.
The main problem is this makes patch loading realllyyy slow on my performance computer, PIII 500.
how slow? i mean, does it matter how slow the patch loads _before_ the performance? does it even take more than one minute?
So I'm going to actually rebuild all of the songs using static objects instead of dynamic ones ... which is too bad because the flexibility of the dynamic objects was nice when creating the song initially. So is that my only option for now, or is there some super trick I haven't noticed?
probably yes: try to switch dsp off, while all the dynamic creations are going on and switch it on only afterwards, when everything is created.
[loadbang] | [t b b b] | | | | | 'switch~ off' | | | 'create all the dynamic stuff' | 'switch~ on'
i could save a lot time by doing this in netpd.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
If an object doesn't have a visual representation, i.e. its not drawn
on a canvas, then it won't have a Tcl/Tk representation at all, so
the slow GUI stuff doesn't apply to things that aren't visible. That
includes non-visible GUI objects.
.hc
On Dec 16, 2007, at 7:15 PM, Daniel Wilcox wrote:
I was under the impression that starting pd without the gui would
take out some of the slow downs assoicated with the gui such as gui object generation. I have some
objects in my rc-patches that build the object based on its creation args such as [rc-seq 16 4]
makes 16 toggle boxes with 4 beat divisions. Now if I have a bunch of these it slows down the
loading of my patch considerably, which I understand ... but it also slows down loading in -nogui mode
which I don't. So is -nogui mode doing all of the tk work but just not drawing the window?The main problem is this makes patch loading realllyyy slow on my
performance computer, PIII 500. So I'm going to actually rebuild all of the songs using static objects instead of dynamic
ones ... which is too bad because the flexibility of the dynamic objects was nice when creating the song
initially. So is that my only option for now, or is there some super trick I haven't noticed?-- Dan Wilcox danomatika www.robotcowboy.com _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Computer science is no more related to the computer than astronomy is
related to the telescope. -Edsger Dykstra
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
If an object doesn't have a visual representation, i.e. its not drawn
on a canvas, then it won't have a Tcl/Tk representation at all, so
the slow GUI stuff doesn't apply to things that aren't visible. That
includes non-visible GUI objects.
Note that in a running patch, even non-visible GUI objects can slow down Pd! For example if you use this:
[select ...] | [random 10]
it's much faster than this:
[select ...] | [bng] <-- GUI bang | [random 10]
even when hidden somewhere deep in an abstraction. Same for floatatoms etc. If you use them for debugging purposes, it's good to disconnect or delete them for the final version of an abstraction.
Ciao
Frank Barknecht _ ______footils.org__
The patch is the same in NOGUI or without, so the more objects there are the more processing it takes to open the patch, then more objects there are the more overhead of them communicating...
Still lots of the GUI (logic) code is in C, and only the drawing in TK. no gui means the tk part don't get run, but I believe the C parts still do.
.b.
Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
If an object doesn't have a visual representation, i.e. its not drawn
on a canvas, then it won't have a Tcl/Tk representation at all, so
the slow GUI stuff doesn't apply to things that aren't visible. That
includes non-visible GUI objects.Note that in a running patch, even non-visible GUI objects can slow down Pd! For example if you use this:
[select ...] | [random 10]
it's much faster than this:
[select ...] | [bng] <-- GUI bang | [random 10]
even when hidden somewhere deep in an abstraction. Same for floatatoms etc. If you use them for debugging purposes, it's good to disconnect or delete them for the final version of an abstraction.
Ciao
-
B. Bogart -
Daniel Wilcox -
Frank Barknecht -
Hans-Christoph Steiner -
Roman Haefeli