Menu
▾
▴
Re: [MACTCL] performance between platforms?
|
From: Jim I. <ji...@ap...> - 2003-10-08 01:15:23
|
I looked at this a little more. If I bring up the widget demo, and exercise Wish a whole bunch, and sample it while I am doing so, the ThreadNotifierProc is almost always found sitting in select (i.e. this thread is just sitting in the kernel using no system resources). So though it is getting fired off more than it ought to, the seems to make no perceptible difference in the app performance. So this may be a non-issue. Also, try as hard as I might, I the only time I could get Tk up above 30% of CPU usage on my machine, and this was by running the main Widget demo screen, and scanning really fast over the text so it had to track the mouse & change the widget colors really fast... It would be interesting to see the full sample as pd is working to see why it is taking up so many resources... Jim On Oct 7, 2003, at 5:44 PM, Jim Ingham wrote: > How does pd-gui differ from Wish? If it is just a custom built wish > shell, then it is probably not significantly different from running > Wish and loading in whatever libraries you use for pd... You are > probably seeing platform differences... > > Can you send the actual sample on X? That would be helpful. > > NotifierThreadProc is run on a separate thread from the main Tk > thread, and is the side of the event loop that is waiting on all input > sources other than the Carbon events, i.e. waits on filehandles, on > stdin, or on sockets. That should spend most of its time sitting > quiet in select (the Unix call that waits for this sort of event). > The problem is that if new stuff to select on arrives (for instance if > you added a socket from Tcl), or we change a timeout, we need to wake > that thread to get it to reread the set of input sources, and then > wait on them again. Looks like we aren't making sure that the state > of the input sources has actually changed, however, and so we wake up > this thread every time we go to wait for a Carbon event regardless. > That's just a bug, and it shouldn't be that hard to keep the state > last time we went to wait, and only wake up the thread if things > actually have changed. > > But you should only see this fire off if you are interacting with the > application. If it is just sitting there doing work, but not fetching > new events, the Notifier Thread shouldn't be waking up that often... > If you have a state where pd is doing something (like redrawing its > display) but you aren't moving the mouse, or typing keystrokes, etc. > do you still see this thread getting waked up often? > > All this code is in tkMacOSXNotify.c. This bit is a little tricky, > but not that bad... The code that wakes up the select loop is in the > same file in TkMacOSXWaitForEvent in the two places where it does: > > write(triggerPipe, "", 1); > > TagSearchFirst is real work, and probably if you sampled pd on X11, > you would find that it was spending lots of time there anyway. So > don't lose heart. It looks like you have removed one of the big time > sinks, with another (DisplayCanvas) in your sights. Then you have > uncovered one more bug that is causing Tk to do work it doesn't need > to. And then the next big thing is something that most likely > represents real work Tk is doing on your behalf. This is the way > performance tuning always works. > > That is pretty good... > > Jim > > > On Oct 7, 2003, at 10:54 AM, tigital wrote: > >> hiya, >> >> ...I recently had a friend test a patch in pd that stresses the >> tcl/tk gui, and had a couple of surprises revealed through "top": >> >> - unix/linux doesn't use wish, it uses pd-gui, which only reports >> 7.5% cpu: X reports 8.5%, and pd itself is 5.3% >> - windows uses wish, and after 4 minutes the wish cpu usage was up to >> 99%!!! I don't know if it matters, but this is wish83.exe... >> - OSX, of course, also uses wish: but with either QuickDraw or >> CoreGraphics, I'm seeing wish take up about 60-70%, while pd reports >> about 6-10%...via profiling/sampling, I know that the >> coregraphicsroutines have reduced pixel swizzling from over 80% of >> Wish Shell to about 10-12%: now the next largest sampled function >> (after DisplayCanvas(), which does the swizzle) is >> NotifierThreadProc(), in tkMacOSXNotify.c; and TagSearchFirst(), in >> CanvasWidgetCmd()... >> >> ...this brings up two major questions: why is there such a big >> difference in cpu usage between osx/windoze and unix/linux? This >> seems to indicate a major problem with wish shell in general...why is >> it so hungry for cpu%? It certainly is a bit disappointing to note >> that my efforts seem to help, but ultimately seem to allow Wish to be >> greedy & inefficient elsewhere... >> >> ...anyone have some insights? >> >> jamie >> >> >> >> ------------------------------------------------------- >> This sf.net email is sponsored by:ThinkGeek >> Welcome to geek heaven. >> http://thinkgeek.com/sf >> _______________________________________________ >> Tcl-mac mailing list >> Tc...@li... >> https://lists.sourceforge.net/lists/listinfo/tcl-mac >> > -- > Jim Ingham ji...@ap... > Developer Tools > Apple Computer > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Tcl-mac mailing list > Tc...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-mac > -- Jim Ingham ji...@ap... Developer Tools Apple Computer |