Dear List,
I'm trying to investigate why does a larger patch slow down the GUI so much much. When opened, CPU load goes to 40-50% (when minimized, goes back to ~20%), when i load values from sssad CPU goes up to 60-70% and stays there, and when i start the metro it goes even higher (not 90 or 100% however) and virtually unresponsive. Please take a look at the attached image and tell me if this is normal with a patch of this visual complexity. Make no mistake, the pd core maintains a decent 3-10% CPU load, its pd-gui which cannot handle the party.
This is an ongoing problem which prevents me from actually *making music* with my patch. Tried to add the GOP abstractions to the canvas one by one, it seems that CPU load goes up by each element, i mean i couldn't find a "guilty one".
Pd 42.5, Ubuntu Lucid, Compiz (<-- does it matter?)
Thanks a lot for any advice!
Andras
without knowing the patch by other than seeing it, I'll give a few
pointers. the gui is the weakest link in Pd, so it's better to make it
efficient
- don't make the objects receive any more "state info" (data used
primarily for display) than necessary. remove repeated values with
[change], or even reduce the rate with [speedlim], if a slider(knob is
there for you to look at it
- in my experience, gop with graphics showing uses more cpu than the same
graphics. try to avoid unecessary gops?
- are your guis in the way of the data flow, like
(process)->(gui)->(synthesis)? if no other solution, use the gui only to
display the parameter's state (at a slower rate) using "set $1" messages.
then when you press it, you still have control of the processes.
Dear List,
I'm trying to investigate why does a larger patch slow down the GUI so
much much. When opened, CPU load goes to 40-50% (when minimized, goes back to ~20%), when i load values from sssad CPU goes up to 60-70% and stays
there, and when i start the metro it goes even higher (not 90 or 100% however)
and virtually unresponsive. Please take a look at the attached image and
tell me if this is normal with a patch of this visual complexity. Make no
mistake, the pd core maintains a decent 3-10% CPU load, its pd-gui which cannot handle the party.This is an ongoing problem which prevents me from actually *making music* with my patch. Tried to add the GOP abstractions to the canvas one by
one, it seems that CPU load goes up by each element, i mean i couldn't find a "guilty one".Pd 42.5, Ubuntu Lucid, Compiz (<-- does it matter?)
Thanks a lot for any advice!
Andras
Thanks João!
On Sun, Sep 26, 2010 at 6:33 PM, João Pais jmmmpais@googlemail.com wrote:
without knowing the patch by other than seeing it,
Well, it's not very exportable as i have modified/overwritten some abstractions made by others. Baaad practice! I'm trying to attach it now and i hope i works. Need pd-extended and many libs from it, moonlib for sure.
I'll give a few pointers. the gui is the weakest link in Pd, so it's better to make it efficient
- don't make the objects receive any more "state info" (data used primarily
for display) than necessary.
Sure. The step seq uses changing background colors and it seemingly makes the GUI sweat...
remove repeated values with [change], or even reduce the rate with [speedlim], if a slider(knob is there for you to look at it
These are already there, and the "alpi_c control" box sends the "control rate" number which is received by every [speedlim]
- in my experience, gop with graphics showing uses more cpu than the same
graphics. try to avoid unecessary gops?
Hm! Sounds interesting. "Unnecessary GOPs" are rare however, because i need to hide the guts and cables to gain space... but i'll experiment and see how it works!
- are your guis in the way of the data flow, like
(process)->(gui)->(synthesis)? if no other solution, use the gui only to display the parameter's state (at a slower rate) using "set $1" messages. then when you press it, you still have control of the processes.
Usually not, but the seq stripes have something like this... BTW the seqs are the most primitive ones... Lots of cables, and i believe not very efficient, so if someone tells me a better way to do the same thing, i'll be happy to try.
Andras
Dear List,
I'm trying to investigate why does a larger patch slow down the GUI so much much. When opened, CPU load goes to 40-50% (when minimized, goes back to ~20%), when i load values from sssad CPU goes up to 60-70% and stays there, and when i start the metro it goes even higher (not 90 or 100% however) and virtually unresponsive. Please take a look at the attached image and tell me if this is normal with a patch of this visual complexity. Make no mistake, the pd core maintains a decent 3-10% CPU load, its pd-gui which cannot handle the party.
This is an ongoing problem which prevents me from actually *making music* with my patch. Tried to add the GOP abstractions to the canvas one by one, it seems that CPU load goes up by each element, i mean i couldn't find a "guilty one".
Pd 42.5, Ubuntu Lucid, Compiz (<-- does it matter?)
Thanks a lot for any advice!
Andras
Well, it's not very exportable as i have modified/overwritten some abstractions made by others. Baaad practice! I'm trying to attach it now and i hope i works. Need pd-extended and many libs from it, moonlib for sure.
not much, some abstractions are missing.
anyway, even with the patch not working, I can see something is
definitively wrong. just by opening it with audio off, I get consistent
50% cpu usage - which means it's using a whole processor of my dual core.
unless one of the missing abs is the problem, I would suggest you spend
some hours bug tracking.
João
On Mon, Sep 27, 2010 at 11:45 AM, João Pais jmmmpais@googlemail.com wrote:
Well, it's not very exportable as i have modified/overwritten some
abstractions made by others. Baaad practice! I'm trying to attach it now and i hope i works. Need pd-extended and many libs from it, moonlib for sure.
not much, some abstractions are missing.
anyway, even with the patch not working, I can see something is definitively wrong. just by opening it with audio off, I get consistent 50% cpu usage - which means it's using a whole processor of my dual core. unless one of the missing abs is the problem, I would suggest you spend some hours bug tracking.
yes, i've spent some nights bug tracking, and at one point i thought ask the list too... :o) something is definitely wrong!
On Mon, Sep 27, 2010 at 3:34 PM, Ivica Ico Bukvic ico@vt.edu wrote:
FWIW you may want to try to simply cut pieces of the patch while it is running and observe the cpu load meter until it drops. That way you should be able to locate the problem quicker.
yes, i was trying thing like this, and will go on until i find what i messed up. I was just starting to think that it's normal and i have to live with it (or get a few more CPU cores) but now you guys reassured me that the bug is somewhere... in the haystack
Andras
maybe this is a bug od pd-gui? (well, poor performance *is* a bug)
2010/9/27 András Murányi muranyia@gmail.com:
On Mon, Sep 27, 2010 at 11:45 AM, João Pais jmmmpais@googlemail.com wrote:
Well, it's not very exportable as i have modified/overwritten some abstractions made by others. Baaad practice! I'm trying to attach it now and i hope i works. Need pd-extended and many libs from it, moonlib for sure.
not much, some abstractions are missing.
anyway, even with the patch not working, I can see something is definitively wrong. just by opening it with audio off, I get consistent 50% cpu usage - which means it's using a whole processor of my dual core. unless one of the missing abs is the problem, I would suggest you spend some hours bug tracking.
yes, i've spent some nights bug tracking, and at one point i thought ask the list too... :o) something is definitely wrong!
On Mon, Sep 27, 2010 at 3:34 PM, Ivica Ico Bukvic ico@vt.edu wrote: FWIW you may want to try to simply cut pieces of the patch while it is running and observe the cpu load meter until it drops. That way you should be able to locate the problem quicker.
yes, i was trying thing like this, and will go on until i find what i messed up. I was just starting to think that it's normal and i have to live with it (or get a few more CPU cores) but now you guys reassured me that the bug is somewhere... in the haystack
Andras
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
well, i meant a bug in my patch... what i understood was that it overloaded the CPU on João's box too
2010/9/28 Bernardo Barros bernardobarros2@gmail.com
maybe this is a bug od pd-gui? (well, poor performance *is* a bug)
2010/9/27 András Murányi muranyia@gmail.com:
On Mon, Sep 27, 2010 at 11:45 AM, João Pais jmmmpais@googlemail.com
wrote:
Well, it's not very exportable as i have modified/overwritten some abstractions made by others. Baaad practice! I'm trying to attach it now and i hope i works. Need pd-extended and
many
libs from it, moonlib for sure.
not much, some abstractions are missing.
anyway, even with the patch not working, I can see something is definitively wrong. just by opening it with audio off, I get consistent
50%
cpu usage - which means it's using a whole processor of my dual core.
unless
one of the missing abs is the problem, I would suggest you spend some
hours
bug tracking.
yes, i've spent some nights bug tracking, and at one point i thought ask
the
list too... :o) something is definitely wrong!
On Mon, Sep 27, 2010 at 3:34 PM, Ivica Ico Bukvic ico@vt.edu wrote: FWIW you may want to try to simply cut pieces of the patch while it is running and observe the cpu load meter until it drops. That way you
should
be able to locate the problem quicker.
yes, i was trying thing like this, and will go on until i find what i
messed
up. I was just starting to think that it's normal and i have to live with it
(or
get a few more CPU cores) but now you guys reassured me that the bug is somewhere... in the haystack
Andras
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
you can post your patch, so maybe we will discover the problem. for the abstraction one solution is to change the name of your hacked abstractions and send them as well.
2010/9/27 András Murányi muranyia@gmail.com:
well, i meant a bug in my patch... what i understood was that it overloaded the CPU on João's box too
2010/9/28 Bernardo Barros bernardobarros2@gmail.com
maybe this is a bug od pd-gui? (well, poor performance *is* a bug)
2010/9/27 András Murányi muranyia@gmail.com:
On Mon, Sep 27, 2010 at 11:45 AM, João Pais jmmmpais@googlemail.com wrote:
Well, it's not very exportable as i have modified/overwritten some abstractions made by others. Baaad practice! I'm trying to attach it now and i hope i works. Need pd-extended and many libs from it, moonlib for sure.
not much, some abstractions are missing.
anyway, even with the patch not working, I can see something is definitively wrong. just by opening it with audio off, I get consistent 50% cpu usage - which means it's using a whole processor of my dual core. unless one of the missing abs is the problem, I would suggest you spend some hours bug tracking.
yes, i've spent some nights bug tracking, and at one point i thought ask the list too... :o) something is definitely wrong!
On Mon, Sep 27, 2010 at 3:34 PM, Ivica Ico Bukvic ico@vt.edu wrote: FWIW you may want to try to simply cut pieces of the patch while it is running and observe the cpu load meter until it drops. That way you should be able to locate the problem quicker.
yes, i was trying thing like this, and will go on until i find what i messed up. I was just starting to think that it's normal and i have to live with it (or get a few more CPU cores) but now you guys reassured me that the bug is somewhere... in the haystack
Andras
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- Muranyi Andras
IOhannes m zmoelnig wrote:
On 2010-09-28 00:32, Bernardo Barros wrote:
(well, poor performance *is* a bug)
i suspect this is not meant seriously, but why post it?
It looks like the gui discussion and 'critique' really reiterates so often :/ IMHO it would be so nice if someone could do a cool (yet simple) proof of concept of "external" GUI (qt, gtk, whatever) + Pd... Wish I had the time right now :)
Lorenzo
fgmas IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Is this not what the 0.43 gui rewrite is about? (or have I misunderstood)
On 28 Sep 2010, at 09:47, Lorenzo wrote:
IOhannes m zmoelnig wrote:
On 2010-09-28 00:32, Bernardo Barros wrote:
(well, poor performance *is* a bug)
i suspect this is not meant seriously, but why post it?
It looks like the gui discussion and 'critique' really reiterates so often :/ IMHO it would be so nice if someone could do a cool (yet simple) proof of concept of "external" GUI (qt, gtk, whatever) + Pd... Wish I had the time right now :)
Lorenzo
fgmas IOhannes
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
well, there is jMax (java gui), that I think would be less efficient since it's, well, java. and there is something done with python+qt here: http://tim.klingt.org/code/projects/nova/repository/revisions/master/show/so...
Is there already some benchmarks of the new puredata gui? Would be nice to have it.
2010/9/28 Lorenzo lsutton@libero.it:
IOhannes m zmoelnig wrote:
On 2010-09-28 00:32, Bernardo Barros wrote:
(well, poor performance *is* a bug)
i suspect this is not meant seriously, but why post it?
It looks like the gui discussion and 'critique' really reiterates so often :/ IMHO it would be so nice if someone could do a cool (yet simple) proof of concept of "external" GUI (qt, gtk, whatever) + Pd... Wish I had the time right now :)
Lorenzo
fgmas IOhannes
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 Tue, 28 Sep 2010, Bernardo Barros wrote:
Is there already some benchmarks of the new puredata gui? Would be nice to have it.
It's nowhere close to being a rewrite : essentially, all of the code that you would benchmark has almost not changed since Pd 42.
| Mathieu Bouchard ------------------------------ Villeray, Montréal, QC
On Tue, 28 Sep 2010, Mathieu Bouchard wrote:
On Tue, 28 Sep 2010, Bernardo Barros wrote:
Is there already some benchmarks of the new puredata gui? Would be nice to have it.
It's nowhere close to being a rewrite : essentially, all of the code that you would benchmark has almost not changed since Pd 42.
I mean it hasn't changed much since way before that time : afair, Pd 38 was the last time there was a speed improvement, and it was due to the addition of sys_queuegui. There were a number of bugfixes and other changes not related to speed.
Much of the speed improvement that can be made, can only be made by modifying Tk's source code itself (or switching to a different renderer).
| Mathieu Bouchard ------------------------------ Villeray, Montréal, QC
On Tue, Sep 28, 2010 at 6:12 PM, Mathieu Bouchard matju@artengine.cawrote:
On Tue, 28 Sep 2010, Mathieu Bouchard wrote:
On Tue, 28 Sep 2010, Bernardo Barros wrote:
Is there already some benchmarks of the new puredata gui? Would be nice to have it.
It's nowhere close to being a rewrite : essentially, all of the code that you would benchmark has almost not changed since Pd 42.
I mean it hasn't changed much since way before that time : afair, Pd 38 was the last time there was a speed improvement, and it was due to the addition of sys_queuegui. There were a number of bugfixes and other changes not related to speed.
Much of the speed improvement that can be made, can only be made by modifying Tk's source code itself (or switching to a different renderer).
...and/or, as far as i understood, reinventing pd in a way that the GUI doesn't chat with the core about gui elements and their properties, but the core is limited to audio and other "abstract" calculations and it's the GUI which takes care of everything that happens on the GUI. I'm not sure if i understood this right, and i suspect that it's a tremendous work, and i also suspect that it may involve externals to be rewritten, but i have a feeling that Tcl/Tk is not that slow by itself but the bottleneck is GUI<->core communication. C'mon, drawing a number with a big font threatens the CPU? On the computers we have, in 2010? I can't believe that.
Andras
Sorry to meddle:
-> Its not "drawing a number" its updating a GUI at a desired speed. Data flows at enormous speeds, GUIs do not, either Tcl or others. When you ask an update on an array, GUI box, etc... that's a lot of stuff happening. But yes, our computers in 2010 are fast as hell. Tcl is an amazing platform, I'm not in need of a faster PD or better GUI but praise all efforts in that direction., just wanted to point out that the GUI of pd is much more than "updating number boxes".
Overall, re-writing the GUI entirely without tcl (aka changing GUI platform) is scary and massive. It would be nice, but its a long long road. At the moment if pd's native GUI does not satisfy me I bind it with another, as3, processing, etc... its not fast (well localhost networking is stupidly fast), but sure is pretty.
Best regards, Pedro
p.s.: interesting exercise for those that wanna see how much time your cpu wastes with gui in pd is running a patch without gui. I had a project that used my DTW in pd and a long patch (for my standards) and when we ran it for the first time without gui... wow. Somethings went faster than expected and some didn't work because it was all too fast :) A bit of cleaning solved it, but its an interesting test for non-visual patches.
2010/9/28 András Murányi muranyia@gmail.com
On Tue, Sep 28, 2010 at 6:12 PM, Mathieu Bouchard matju@artengine.cawrote:
On Tue, 28 Sep 2010, Mathieu Bouchard wrote:
On Tue, 28 Sep 2010, Bernardo Barros wrote:
Is there already some benchmarks of the new puredata gui? Would be nice to have it.
It's nowhere close to being a rewrite : essentially, all of the code that you would benchmark has almost not changed since Pd 42.
I mean it hasn't changed much since way before that time : afair, Pd 38 was the last time there was a speed improvement, and it was due to the addition of sys_queuegui. There were a number of bugfixes and other changes not related to speed.
Much of the speed improvement that can be made, can only be made by modifying Tk's source code itself (or switching to a different renderer).
...and/or, as far as i understood, reinventing pd in a way that the GUI doesn't chat with the core about gui elements and their properties, but the core is limited to audio and other "abstract" calculations and it's the GUI which takes care of everything that happens on the GUI. I'm not sure if i understood this right, and i suspect that it's a tremendous work, and i also suspect that it may involve externals to be rewritten, but i have a feeling that Tcl/Tk is not that slow by itself but the bottleneck is GUI<->core communication. C'mon, drawing a number with a big font threatens the CPU? On the computers we have, in 2010? I can't believe that.
Andras
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
p.s.: interesting exercise for those that wanna see how much time your
cpu wastes with gui in pd is running a patch without gui. I had a project
that used my DTW in pd and a long patch (for my standards) and when we ran it
for the first time without gui... wow. Somethings went faster than expected
and some didn't work because it was all too fast :) A bit of cleaning solved
it, but its an interesting test for non-visual patches.
if you know a good way to measure this (cputime or whatever), a nice thing
could be an abstraction that makes a test and outputs the results.
I had my sort of tester by using the shell object and printing time and messages. I have come across some pd patch that tests the audio latency and so forth.. I think its in the browser of pd-extended somewhere.
Best regards, Pedro Lopes
2010/9/29 João Pais jmmmpais@googlemail.com
p.s.: interesting exercise for those that wanna see how much time your cpu
wastes with gui in pd is running a patch without gui. I had a project that used my DTW in pd and a long patch (for my standards) and when we ran it for the first time without gui... wow. Somethings went faster than expected and some didn't work because it was all too fast :) A bit of cleaning solved it, but its an interesting test for non-visual patches.
if you know a good way to measure this (cputime or whatever), a nice thing could be an abstraction that makes a test and outputs the results.
On Wed, 29 Sep 2010, João Pais wrote:
p.s.: interesting exercise for those that wanna see how much time your cpu wastes with gui in pd is running a patch without gui. I had a project that used my DTW in pd and a long patch (for my standards) and when we ran it for the first time without gui... wow. Somethings went faster than expected and some didn't work because it was all too fast :) A bit of cleaning solved it, but its an interesting test for non-visual patches.
if you know a good way to measure this (cputime or whatever), a nice thing could be an abstraction that makes a test and outputs the results.
It can't be done without modifying Tk. But if I do modify Tk in a way that puts the results in variables, then I can pick up the results in Tcl and send them back to Pd, so that, in addition to [cputime] which measures only server time, you'd have a few more measurements, such as total time spent in Tcl/Tk, total time spent in the Tk part, total time spend in the rendering part of the Tk part, total time spent parsing, etc.
| Mathieu Bouchard ------------------------------ Villeray, Montréal, QC
It can't be done without modifying Tk. But if I do modify Tk in a way
that puts the results in variables, then I can pick up the results in Tcl and send them back to Pd, so that, in addition to [cputime] which measures only server time, you'd have a few more measurements, such as total time spent in Tcl/Tk, total time spent in the Tk part, total time spend in the rendering part of the Tk part, total time spent parsing, etc.
that could be interesting to measure tcl/tk efficiency and etc. For
example, once I had a data structures patch with gop, that took me around
20% cpu. I put it on gem, and it went to 0% - it wasn't a rough patch, but
I think the whole gop+graphics was taking too much cpu.
On Tue, 28 Sep 2010, András Murányi wrote:
Much of the speed improvement that can be made, can only be made by modifying Tk's source code itself (or switching to a different renderer).
I spoke a bit too fast. It depends on the situation. Still it's easy to make the GUI spend 75 ms on a single draw, it's just that there's something else sucking 1000 ms at the same time. There are some other situations where it's the opposite. But this is made by measuring times directly in the idle-function of tk/src/generic/tkCanvas.c and adding a XSync so that I get the time of a ping to the X server included in the figures (make sure the X11 commands are sent and applied, not just buffered in the tk process).
...and/or, as far as i understood, reinventing pd in a way that the GUI doesn't chat with the core about gui elements and their properties, but the core is limited to audio and other "abstract" calculations and it's the GUI which takes care of everything that happens on the GUI.
I made something close to this already... but it's not automatically faster.
but i have a feeling that Tcl/Tk is not that slow by itself but the bottleneck is GUI<->core communication. C'mon, drawing a number with a big font threatens the CPU? On the computers we have, in 2010? I can't believe that.
Then why would you believe that the TCP/IP loopback that is used to communicate between Pd server and client would be any slower than a gigabit ethernet ?... On the computers we have, in 2010 ? It's not like it's going over a RS232 serial pork.
So, the answer is trickier than that. There are several other parts standing between a gui object and the X11 server. Here's the complete chain :
- GUI Object
- sys_vgui commands and the output buffer
- the TCP socket pair in loopback mode
- the input buffer
- [info complete] or equivalent
- [eval] or equivalent
- Tk Canvas commands
- Tk Canvas renderer
- Xlib and its output buffer
- the unix socket pair
- X server
Now, which ones of the above takes so much time, and how do you measure that ? Using only [cputime] will only give you the time of steps 1, 2, and part of 3. Using measurements in t_tkcmd.c (42) or pd_connect.tcl (43) will only give you info about 4, 5, 6, 7, and part of 3. The measurement I make from tkCanvas.c only gives me info about 8, 9, 10 and 11.
We need more measurements.
| Mathieu Bouchard ------------------------------ Villeray, Montréal, QC
On Sep 28, 2010, at 4:02 PM, Mathieu Bouchard wrote:
On Tue, 28 Sep 2010, Bernardo Barros wrote:
Is there already some benchmarks of the new puredata gui? Would be
nice to have it.It's nowhere close to being a rewrite : essentially, all of the code
that you would benchmark has almost not changed since Pd 42.
Matju, its really not helpful to anyone for you to keep talking like
this. So I guess I spent of month or more of coding to do nothing,
according to you, because somehow it doesn't meet your definition of
rewrite.
Everything related to the GUI was not rewritten. The whole body of
the Tcl code that's not embedded in the C code was rewritten. Much
code was taken from the old Tcl code and refactored into the new
(mostly iemgui stuff). This is the first phase. The next phase is
rewriting the pd --> pd-gui message API so that pd sends Pd messages
to the GUI and not Tcl code.
From what I have seen, the big problem is that pd currently generates
massive amounts of Tcl code when drawing things like array boxes.
This needs to be sent over the network, parsed, compiled, and then
run. That's a lot of overhead IMHO. The pd --> pd-gui messages should
not require new code to be parsed/compiled/run. To me, once I found
this out, I was impressed at how fast the Tcl interpreter seems to be.
.hc
I spent 33 years and four months in active military service and during
that period I spent most of my time as a high class muscle man for Big
Business, for Wall Street and the bankers. - General Smedley Butler
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/05/2010 11:39 AM, Hans-Christoph Steiner wrote:
On Sep 28, 2010, at 4:02 PM, Mathieu Bouchard wrote:
It's nowhere close to being a rewrite : essentially, all of the code that you would benchmark has almost not changed since Pd 42.
Everything related to the GUI was not rewritten.
for future conversation i'd suggest the term "the GUI has been refactored".
mfsdar IOhannes
On Tue, 5 Oct 2010, IOhannes m zmölnig wrote:
On 10/05/2010 11:39 AM, Hans-Christoph Steiner wrote:
Everything related to the GUI was not rewritten.
for future conversation i'd suggest the term "the GUI has been refactored".
But that's not even true. The GUI also includes the C code of IEMGUI, the C code of objectbox, messagebox, gatom, comment, the C code of canvas (which is the longest and toughest part), the C code of arrays, the C code of drawpolygon, drawnumber, scalars, etc.
And the GUI's C code has a lot more meat to it than the Tcl code. I should know, because I rewrote most of the C GUI code in Tcl already, and I rewrote (with Chun) essentially all of the Tcl GUI code already as well (including the whole of the Tcl code that Hans didn't touch).
| Mathieu Bouchard ------------------------------ Villeray, Montréal, QC
On Tue, 5 Oct 2010, Hans-Christoph Steiner wrote:
Matju, its really not helpful to anyone for you to keep talking like this.
Hans, it's really not helpful to anyone for you to keep talking like this.
So I guess I spent of month or more of coding to do nothing, according to you,
That's not according to me. I didn't say that. What kind of words are you putting in my mouth ?
because somehow it doesn't meet your definition of rewrite.
I did not come up with that definition. Talking using your definition of 'GUI' and of 'rewrite' makes people believe that you did something that would take 3 or 5 times more time than you really did... Perhaps even more.
Everything related to the GUI was not rewritten. The whole body of the Tcl code that's not embedded in the C code was rewritten. Much code was taken from the old Tcl code and refactored into the new (mostly iemgui stuff).
Can you say that the whole body of Tcl code was not rewritten because you took much code nearly as-is from the old Tcl code, such as several of the dialog_*.tcl files ?
The next phase is rewriting the pd --> pd-gui message API so that pd sends Pd messages to the GUI and not Tcl code.
That's interesting, but in itself, it won't solve anything, as you can achieve the same by sending much smaller Tcl code. Note that parsing Pd messages takes time, but it takes especially more time if you try to do it correctly instead of running a dumb [split $code].
From what I have seen, the big problem is that pd currently generates massive amounts of Tcl code when drawing things like array boxes. This needs to be sent over the network, parsed, compiled, and then run. That's a lot of overhead IMHO. The pd --> pd-gui messages should not require new code to be parsed/compiled/run. To me, once I found this out, I was impressed at how fast the Tcl interpreter seems to be.
But did you get figures that support the idea that the generated code is a slowdown and that it's more of a slowdown than what you plan to do ?
| Mathieu Bouchard ------------------------------ Villeray, Montréal, QC
this tread is about gui performance, isn't it?
2010/9/28 IOhannes m zmoelnig zmoelnig@iem.at:
On 2010-09-28 00:32, Bernardo Barros wrote:
(well, poor performance *is* a bug)
i suspect this is not meant seriously, but why post it?
fgmas IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
András Murányi -
Bernardo Barros -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
João Pais -
Lorenzo -
Mathieu Bouchard -
Pedro Lopes -
Si Mills