At 2:18 PM -0700 6/22/03, Josh Steiner wrote:
http://www.gnu.org/manual/gprof-2.9.1/html_mono/gprof.html
or
those pretty look useful but they are different from shikari in that they are both profilers for specific apps that require traces to be produced for the profiler to breakdown. shikari is a system wide profiler that records every function running on the machine, which allows you to see problems that exist outside of your app. it's a really amazing thing to use when writing code, and i've become somewhat dependent on it. oh and there's another little OSX tool called OpenGL Profiler that i'm fond of as well. ;)
it looks like in this thread from the profiling data jamie posted that tcl/tk is not the culprit in this case, thouse i wouldnt be surprised if it were in many other instances. i'm wondering though, how extensively have you profiled your code to find out if it really an archetectural flaw in tcl/tk? are there other large tcl/tk applications we know of that we could test and/or look into the code of to see if they are able to squeeze better performance out of?
there is a huge flaw in the way the pd and/or tcl/tk does screen updates on OSX. i posted an example of this a while back which illustrated this by putting two number boxes in the opposite corners of a large pd patcher. the number boxes displayed the output of a random object fed by a metro, and turning one on didn't use much CPU but turning the second on created a huge spike. when i used the OSX app QuartzDebug to show the are of the screen updated by the patch, it revealed that the entire area in between the two boxes was updated not just the two number boxes. this is of course hugely inefficient and completely wasteful, but i have yet to figure out if it's something done by pd or by tcl/tk in general.
At 3:19 PM -0700 6/22/03, Josh Steiner wrote:
you want the [switch~] object, it disables audio processing in subpatches
oh yeah that's the ticket. i can't believe i forgot about that.