🚀 go-pugleaf

> In article <1992Dec29.044957.19576@llyene.jpl.nasa.gov>, john@pluto.Jpl.Nasa.Gov (John R Veregge) writes:
>> We have developed several large Motif applications that are complete CPU
>> hogs and I don't know why.
>> 
>> Each application has 300 to 500 XtCreateWidget() and 8 XtAppCreateShell()
>> calls. These calls are all made before XtAppMainLoop() is called. Widgets
>> are not destroyed until the application exits.
>> 
>> Each application is driven by both the GUI and serialized data using
>> XtInputCallbackProc's.
>> 
>> We run 2 to 4 application on a workstation.
>> 
>> 2 applications will put CPU usage of a Sparc 2 at 97%, even when
>> completely idle with no serialized data input and no X events (GUI input),
>> using X11R4, on Sun Sparc 2's with 32+ megs of memory and 20+ megs of swap.
>> 
>> Can anyone tell me (1) Why? and (2) How can I fix (optimize) this?

The problem was in XtAppAddInput()...

The application read two sockets and a Bourne shell pipe from stdin. I had
dutifully read the FAQ prior to posting so I 'knew' the problem could not be
XtAppAddInput() doing select() on a regular file. I also performed a profile
in the testing environment and found no obvious problems prior to posting.

The problem was that the test environment used the highest data rate the
application could handle, while the user's environment had much slower data
rates, with lots of idle time.  It was during this idle time that select()
kept getting called and in turn causing the XtAppAddInput() callbacks to be
called. When the input was completely idle, the application was chewing up 90%
of the CPU and 75% of it's time was spent in 4500 select() calls per second.

I switched to using XtAppAddTimeout() with an interval that adjusts to the
data rate and prioritizes X events ahead of input events. This solved the
problem. Weird, but it worked. (-;

Thanks to all who replied.
________________________________________________

 John R Veregge		john@proteus.jpl.nasa.gov