Re: macOS metal rendering engine in mac port

[Aaron Jensen]

On Mon, May 24, 2021 at 12:37 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> Why does it look suspect to you?  Don't you also see the same code called to 
> process the other faces in the buffer?

What looks suspect is that the exact same call is made so many times
for the exact same faces and that call gets slower proportional to the
number of faces you have because of the linear search. Fewer faces ==
less work, and when something is called so many times it may be worth
further optimization or caching.

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

I'm not sure I track your last question. In my case it's the addition
of 400-600 faces, none of which are used in the buffer. They just
exist in the alist that lface_from_face_name_no_resolve scans with
assq_no_quit. This is why TAGGEDP via CONSP is a hotspot in my code,
because it's called 600 * 700k (or some multiple thereof) times or so.
assq_no_quit via merge_faces accounts for 1.43s of 6.94s in one of my
profiles.