Re: macOS metal rendering engine in mac port

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Sat, 22 May 2021 09:01:03 -0700
> 
> While profiling this, many signs point to line number display being a
> hot spot when display-line-numbers-mode is enabled. Specifically,
> maybe_produce_line_number calling merge_faces. Ultimately, most of the
> time is spent in TAGGEDP which is called by CONSP in assq_no_quit.
> 
> Here's a reverse tree: https://cln.sh/nLrew6

This profile is shown in reverse, so it's hard to interpret it.  Are
the numbers cumulative, or are they self-percents?  If the latter, I
cannot understand why CONSP is such a hot spot, it sounds improbable.

Did you customize the line-number face? if so, what happens if you
don't?  If you didn't customize the face, I don't think I understand
why we need to spend so much time in face-merging.  Or maybe you have
a lot of faces defined?

Also, if you run the scroll-benchmark with and without line numbers,
how much do the results differ?

> Is there anything that can be done for caching the merged face?

Emacs always caches every face it realizes, so that is already done.
Unless you have some Lisp hooks that somehow invalidate the face
cache, what you see is with the face cache being used.

Anyway, what you see sounds strange.  When I added
display-line-numbers, I measured the effect on redisplay and found it
negligible.  About the only situation where it was tangible was with
visual-mode line numbers, and even then the slowdown was around 10%.
So I don't know how to explain what you perceive as significant
slowdown.