On Nov 14, 2007 11:18 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:

> William Gallafent writes:
>
>  > few lines of build posted below. Any idea what's causing the duplicate
>  > symbol?
>
> The GNU buildchain's "extern inline" support is disabled or broken
> under Xcode.
>

I believe the problem here is the "-std=c99" in William's CFLAGS.  The
meaning of "extern inline" in C99 is different from the historical GCC
meaning.  The C99 spec, section 6.7.4, says that "inline" gives you a
function that is completely inlined, with no external linkage possible, and
"extern inline" means that you inline calls to that function from within the
same compilation unit, but also leave behind an actual function that can be
called by external code.  GCC used to define "extern inline" to mean what
C99 now calls "inline", and "inline" to mean approximately what C99 now
calls "extern inline".

We need to put C99 detection into our configure script and adjust the inline
keywords accordingly.  In the meantime, William, remove the "-std=c99" from
your CFLAGS and let us know if that works.
-- 
Jerry James
http://loganjerry.googlepages.com/

On 14 Nov 2007, at 22:22, Stephen J. Turnbull wrote:

> Please BCC the Apple lists, they just cause annoying rejection notices
> for us.

Sure, no problem, sorry about that!

William Gallafent <william@gallaf.net> writes:

> Does anyone know of an Xft speed test application that I could use to see
> which operations are slow? (Or just another Xft-intensive  applicatiion which
> I could install (ideally from macports!) ...)
>
> On another note, I have now observed that there are a number of X Errors being
> reported in the console from which XEmacs is being run.

> X Error of failed request:  BadMatch (invalid parameter attributes)
>   Major opcode of failed request:  66 (X_PolySegment)
>   Serial number of failed request:  78700
>   Current serial number in output stream:  78709

I first tried XFT xemacs after installing leopard and found it
very appealing, but with an unusably slow redraw (think 2400 baud :-).
Also saw tons of BadMatch on X_PolySegment as above.

After upgrading X using the developer (unofficial) build from

    http://trac.macosforge.org/projects/xquartz/wiki/Releases

and rebuilding XEmacs it all works great.  On perception alone, it
seems just as fast to me as non-XFT XEmacs, altho cpu usage maybe
a bit higher when typing.

On 2 Nov 2007, at 11:07, Aidan Kehoe wrote:
> Are other XFT apps as slow for you? Could it be that the fontconfig  
> cache
> was not created?

Thanks for the suggestions!

Well, it looks from the outside as if the fontconfig cache is there.  
Is there a way to check that it's being used? I have 30 files in  
~/.fontconfig, one of 358KB, two 282KB, two 281KB, others ranging down  
through tens of KB to several of the smallest ones at 80B. Dates are  
yesterday and the day before!

Does anyone know of an Xft speed test application that I could use to  
see which operations are slow? (Or just another Xft-intensive  
applicatiion which I could install (ideally from macports!) ...)

On another note, I have now observed that there are a number of X  
Errors being reported in the console from which XEmacs is being run.  
Here are the last few. Could they be responsible for this slowdown?

...
   Serial number of failed request:  78699
   Current serial number in output stream:  78709
X Error of failed request:  BadMatch (invalid parameter attributes)
   Major opcode of failed request:  66 (X_PolySegment)
   Serial number of failed request:  78700
   Current serial number in output stream:  78709
X Error of failed request:  BadMatch (invalid parameter attributes)
   Major opcode of failed request:  66 (X_PolySegment)
   Serial number of failed request:  78701
   Current serial number in output stream:  78709
X Error of failed request:  BadMatch (invalid parameter attributes)
   Major opcode of failed request:  66 (X_PolySegment)
   Serial number of failed request:  78702
   Current serial number in output stream:  78709
X Error of failed request:  BadMatch (invalid parameter attributes)
   Major opcode of failed request:  70 (X_PolyFillRectangle)
   Serial number of failed request:  78703
   Current serial number in output stream:  78709
X Error of failed request:  BadMatch (invalid parameter attributes)
   Major opcode of failed request:  66 (X_PolySegment)
   Serial number of failed request:  78704
   Current serial number in output stream:  78709
X Error of failed request:  BadMatch (invalid parameter attributes)
   Major opcode of failed request:  66 (X_PolySegment)
   Serial number of failed request:  78705
   Current serial number in output stream:  78709
X Error of failed request:  BadMatch (invalid parameter attributes)
   Major opcode of failed request:  64 (X_PolyPoint)
   Serial number of failed request:  78706
   Current serial number in output stream:  78709
X Error of failed request:  BadMatch (invalid parameter attributes)
   Major opcode of failed request:  66 (X_PolySegment)
   Serial number of failed request:  78707
   Current serial number in output stream:  78709
X Error of failed request:  BadMatch (invalid parameter attributes)
   Major opcode of failed request:  66 (X_PolySegment)
   Serial number of failed request:  78708
   Current serial number in output stream:  78709
X Error of failed request:  BadMatch (invalid parameter attributes)
   Major opcode of failed request:  152 (RENDER)
   Minor opcode of failed request:  4 (RenderCreatePicture)
   Serial number of failed request:  78712
   Current serial number in output stream:  78719
X Error of failed request:  RenderBadPicture (invalid Picture parameter)
   Major opcode of failed request:  152 (RENDER)
   Minor opcode of failed request:  23 (RenderCompositeGlyphs8)
     Picture id in failed request: 0x800233
Serial number of failed request:  78713
   Current serial number in output stream:  78719
X Error of failed request:  RenderBadPicture (invalid Picture parameter)
   Major opcode of failed request:  152 (RENDER)
   Minor opcode of failed request:  7 (RenderFreePicture)
     Picture id in failed request: 0x800233
Serial number of failed request:  78714
   Current serial number in output stream:  78719

_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta@xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

On 1 Nov 2007, at 15:00, X11-users.apple.mzs@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@xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

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.

There is a nice write-up in section 9 of this paper about using DTrace for 
similar ends:

http://www.usenix.org/event/usenix04/tech/general/full_papers/cantrill/cantrill_html/

mzs

On Thu, 1 Nov 2007, William Gallafent - william@gallaf.net wrote:

> Well, I did a quick "Sampler" run.
>
> I just pressed page up and page down a few times, and all the time spent was 
> redrawing the text on the screen.
>
> This time is apparently being spent in "poll$UNIX2003" from _XRead <- 
> _XReply <- XQueryColor <- xft_convert_color, and "select$DARWIN_EXTSN", from 
> XtAppProcessEvent <- emacs_Xt_next_event.
>
> Anybody know why this might be?
>
> (There is a message with the actual Sampler run attached  (24KB zipped!) 
> awaiting moderation ...)
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> X11-users mailing list      (X11-users@lists.apple.com)
> Help/Unsubscribe/Update your Subscription: 
> http://lists.apple.com/mailman/options/x11-users/x11-users.apple.mzs%40spamgourmet.com
>
> This email sent to x11-users.apple.mzs@spamgourmet.com

_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta@xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

On 1 Nov 2007, at 11:00, William Gallafent wrote:
> So, what information should I gather (this might be a good way to  
> learn my way around "Instruments"!)

Well, I did a quick "Sampler" run, which seems to be similar to Shark  
(but where's the button to make it "descend all the way down the most  
expensive path" gone?) ... and the results are attached.

I just pressed page up and page down a few times, and all the time  
spent was redrawing the text on the screen.

This time is apparently being spent in "poll$UNIX2003" from _XRead <-   
_XReply <- XQueryColor <- xft_convert_color, and "select 
$DARWIN_EXTSN", from XtAppProcessEvent <- emacs_Xt_next_event.

Anybody know why this might be?

Hi,

I recently built (using XCode 3.0 toolchain, on Mac OS X 1.05) XEmacs  
21.5.28, targetting X11 with xft. My configure line was:

./configure --with-xft=emacs,tabs,menubars,gauges --with-mule --with-x  
--x-includes=/usr/X11/include --x-libraries=/usr/X11/lib --with-error- 
checking=none

This builds, installs, and runs well under Apple's X11 2.0, except for  
one thing: font redraw is glacially slow! (This is on a 4x2.66GHz Mac  
Pro...)

I found the thread titled "Xft performance" in the Apple X11-users  
list, which was started by Eric Knauel on 2003-07-28 (!), but no  
particular conclusion was reached there.

Since I'm seeing a significant performance problem here with the  
latest Apple tools and hardware, I'm hoping that I can help to fix it  
(either in XEmacs or in Apple's X11) by doing some diagnostics on this  
machine to determine where the problem lies. XEmacs built in a similar  
way running on e.g. stock Kubuntu 7.10, on significantly slower  
hardware, does not exhibit this performance problem.

So, what information should I gather (this might be a good way to  
learn my way around "Instruments"!)

_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta@xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta