Re: macOS metal rendering engine in mac port

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Tue, 25 May 2021 08:35:42 -0700
> Cc: emacs-devel@gnu.org, Alan Third <alan@idiocy.org>, 
>       YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> 
> > The 17% is about twice what I'd expect, since adding 3 characters to
> > each line of xdisp.c enlarges its text by only 9.3%.
> 
> Pure guess here, but it's also making a lot of empty lines non-empty
> (14% more). Perhaps that has an added cost somehow?

Not AFAIU, but I had so many surprises in this investigation that I no
longer believe in my intuition.  So who knows, maybe you are right.

> > How did you compile Emacs? which compiler and what compiler and linker
> > switches?  And what kind of CPU do you have there?  I'm looking for
> > something that could explain why parts of code that should take like
> > 20% of the total redisplay time are so dominant in your case.
> 
> clang, with -O2. Specifically these configure flags:
> 
> CFLAGS="-g3 -O2" \
> --disable-silent-rules \
> --with-xml2 \
> --with-gnutls \
> --without-dbus \
> --with-imagemagick \
> --with-modules \
> --with-rsvg \
> --with-ns \
> --disable-ns-self-contained
> 
> 
> This CPU: Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz

So you have 16 execution units, but a relatively slow clock.  Hmm...

> > Alan, do you see similar numbers (in percents) to what Aaron reports?
> > Or is that something peculiar to his system?
> 
> What I get depends on frame size and whether or not I'm using
> nativecomp or Alan's branch or master. I just a test with a smaller
> frame size (on Alan's branch this time, just happens to be what I have
> built) and saw 5.58 vs 6.8s: 22%. But then I ran the bench again w/
> line numbers and couldn't get it below 7.2s, so there's quite a bit of
> variability in the test runs.

FWIW, in my case, the default frame size (~37 lines) and a maximized
frame produce the same timings here.