Re: macOS metal rendering engine in mac port

[Aaron Jensen <aaronjensen@gmail.com>]

On Mon, May 24, 2021 at 11:55 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> 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.

Okay, is there something else you want me to measure?

> 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.

lface_from_face_name_no_resolve is called 4.5x more often when line
numbers are enabled and that's enough to make a difference on my
machine.

> 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.

Could you try adding 500 extra (unused) faces and try the comparison
again? The slowdown scales along with the number of faces, so your
linux build may just be better optimized for this particular scenario.

> 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.

emacs -Q
No highlights: 5.47s (slower likely because i'm on master now instead
of Alan's branch)
With highlights: 9.4s

So yes, a similar slowdown for me.