Re: macOS metal rendering engine in mac port

[Eli Zaretskii]

On May 24, 2021 11:07:42 AM GMT+03:00, Aaron Jensen <aaronjensen@gmail.com> 
wrote:
> 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.

But we do the same for every face in the buffer, not just for the line-number 
face.  When you turn on the line-numbers display, a single face gets added to 
the faces used by buffer text -- the font-lock faces each major mode uses.  So 
how come adding just one face to the dozen of others has such effect?

You are right that there are better ways than linear search to look up a face's 
attributes by its symbol, and there is a patch in the works to do just that.  
But the puzzle here is elsewhere.  Especially since you report significant 
slowdown due to line numbers in "emacs -Q" as well.

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

But the same face alist is searched for faces that _are_ in the buffer: all the 
font-lock faces.  The line-number face adds just one face to those which Emacs 
must look up in that alist.

IOW, what puzzles me is not the difference between "emacs -Q" and your 
customizations, what puzzles me is the difference betwen with and without the 
line numbers, in the same basic configuration.  It cannot be explained by the 
length of the frame's face alist alone because in both cases that length is 
almost identical: you add one face to the list of hundreds.

 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.

How many times is it called with line numbers turned off, and what is the 
increase in the number of calls due to line numbers in percents?  Does it come 
anywhere near the slowdown shown in your benchmarks?