On 1 Nov 2007, at 15:00, X11-users.apple.mzs(a)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?
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta