Re: macOS metal rendering engine in mac port

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Mon, 24 May 2021 11:18:10 -0700
> Cc: emacs-devel@gnu.org, Alan Third <alan@idiocy.org>, 
>       YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> 
> On Mon, May 24, 2021 at 11:03 AM Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > I said merge_face_ref, not merge_faces.  See face_at_buffer_position,
> > which is called whenever the display code finds a new face at some
> > buffer position.
> 
> I see. I was counting merge_faces, but the below numbers are for
> merge_face_ref on the master branch.
> 
> First run (no line numbers): 131,080
> Second run (no line numbers): 130,376
> Run with line numbers: 836,569
> 
> 640% increase

That's not the interesting comparison of numbers, because this
function is called recursively.  What is important is that
merge_face_ref is called on behalf of buffer faces roughly the same
number of times as merge_face is called on behalf of line numbers:
about 130,000 to 140,000 for scrolling through xdisp.c.  IOW, the
number of face merges is doubled, it doesn't become 6-fold.

Thus, the slowdown you see in "emacs -Q" is still a mystery for me,
because face merging is far from being the most expensive part of
redisplay.

Maybe there's something NS-specific here, I don't know.  I cannot
explain what you see, and I don't see it on my system.

If you turn on highlight-regexp mode, and use regexps that match about
2 times on each line, do you also see a similar slowdown in the
scrolling benchmark?  For example, highlight two regexps: "^." and
".$".  This should create the same addition of face merges per line as
with line numbers, and so the effect should be similar -- if indeed
the reason is face merges and not something else.  In my testing,
scrolling through xdisp.c with the above 2 regexps highlighted takes
just 2% more time than without them, similar to what I see when I turn
on line numbers.