Xft performance with XEmacs 21.5.28 on Mac OS 10.5

[William Gallafent]

On 1 Nov 2007, at 15:00, X11-users.apple.mzs at spamgourmet.com wrote:

> I think you should sample the X server instead of emacs.  
> emacs_Xt_next_event() is how emacs handles events. In X all the on- 
> screen work is actually done by another process, the X server  
> (Xquartz in this case). The poll() is for the descriptor used to  
> comminucate between X server and emacs. You should sample Xquartz  
> and see what is taking so much time.

Good plan. I've done this, and find that the bulk of the time is spent  
in a few places:

ProcRenderFillRectangles ... ProcPolyFillRectangle ->  
RootlessPolyFillRect ... _CGSLockWindow ->  
_CGSSynchronizeWindowBackingStore -> mach_msg_trap

... from XQuartz's Dispatch, time is also spent in select$DARWIN_EXTSN

... and more in libXplugin.1.dylib, spending time in:

... _xp_async_dequeue -> pthread_cond_wait$UNIX2003 -> __semwait_signal

... the event loop also spends all its time in mach_msg_trap, less  
surprisingly.

The point is that the actual CPU load during all these operations  
remains mostly very low, with occasional spikes. It looks as if  
everything is spending all its time waiting for synchronisation with  
something else ... I can send the trace to anyone interested (but  
won't attach it here).

Is XQuartz doing something synchronously which other XServers I've  
used do asynchronously, perhaps?