Re: macOS metal rendering engine in mac port

[Aaron Jensen]

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

It's not the extra face. It appears that enabling line numbers calls
merge_faces for those two faces a significant number of times. See
below.

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

Awesome!

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

Agreed, I was only pointing out the length compounding things because
I made the likely incorrect assumption that the number of times
merge_faces was called when line numbers are turned on was expected.

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

With it turned off, merge_faces was called 40 times.
lface_from_face_name_no_resolve was called 143,308 times.

With it on, merge_faces was called 147,882 times and
lface_from_face_name_no_resolve was called 661,238

merge_faces: 369705% more calls
lface_from_face_name_no_resolve: 461% more calls

I'll respond to your second email separately.