On Monday, September 15, 2003, at 02:20 PM, Amos Elmaliah wrote:
hi list, more OSX question; on what mostly does the performance level of pd rely? tk / compiler / actual code ? amos.
hi amos,
...by what do you mean performance? It is very easy to create an unusable patch by incorporating lots of number output boxes, or other visual feedback, and this is a cross-platform problem of using Tcl/Tk...however, as I mentioned previously, the specific implementation of Tk on OSX is based on quickdraw calls, which incur a huge penalty due to conversion of xrgb to argb pixels when redrawing parts of the screen; simple examples using only two number output boxes have been posted, showing that the "wish shell" hungrily takes up ~80% cpu, of which ~30-40% come from the pixel conversion (and that is using an altivec algorithm, to boot!)...
...I don't know of anyone successfully compiling pd or GEM on OSX using a compiler other than gcc, but it seems to be pretty well known that we could expect "faster" code; how much faster would be a total guess...
...as a last thought, it seems that alot of people new to pd, GEM, or
any other program are concerned with making it as fast as possible;
but this just reminds me of the old addage about "premature
optimization is the hobgoblin of programming"...meaning it's better to
get something working, then worry about performance improvements, if
necessary...I've found that some pretty amazing stuff can be
accomplished with pd/GEM, even with the current caveats ;-)
l8r, jamie