Re: macOS metal rendering engine in mac port

[Eli Zaretskii]

On May 24, 2021 9:51:42 AM GMT+03:00, Aaron Jensen <aaronjensen@gmail.com> 
wrote:
> On Sun, May 23, 2021 at 8:56 PM Aaron Jensen <aaronjensen@gmail.com>
> wrote:
> >
> > Here are some interesting profile pictures. On the left is emacs -Q
> w/
> > display-line-numbers-mode. On the right is a partial version of my
> > config with some of the things I mentioned before removed. Most of
> the
> > difference between the two comes in the amount of time spent in
> > merge_faces. My config ends up spending roughly 7.5x more time in
> > merge_faces (1500ms vs 200ms). What causes that to get slower?
> 
> One thing of note is that emacs -Q has 129 faces for me. My config has
> anywhere from 600-800 faces depending on what's loaded it looks like.
> lface_from_face_name_no_resolve does a linear time search for a face
> every time it's called. It's called over 700k times when I do my
> xdisp.c scroll up test. merge_faces is called over 150k times, each
> time with line-number-current-line or line-number and 0's for face_id
> and base_face_id. I don't really know what this code is doing at all,
> but all of this seems suspect. Thoughts?

Why does it look suspect to you?  Don't you also see the same code called to 
process the other faces in the buffer?

An Emacs face that is identified by name needs to be converted to the 
collection of the face's attributes, so that Emacs could merge faces and 
display them.  This is what lface_from_face_name does.  And it does that for 
any face specified in the buffer by its symbol.  So how come addition of just 
one face and a few characters which have that face have such a profound effect 
in your case?