Re: macOS metal rendering engine in mac port

[Aaron Jensen]

On Sat, May 29, 2021 at 12:05 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Aaron Jensen <aaronjensen@gmail.com>
> > Date: Sat, 29 May 2021 00:01:31 -0700
> > Cc: Alan Third <alan@idiocy.org>, emacs-devel@gnu.org
> >
> > On Fri, May 28, 2021 at 11:07 PM Eli Zaretskii <eliz@gnu.org> wrote:
> > >
> > > > From: Aaron Jensen <aaronjensen@gmail.com>
> > > > Date: Fri, 28 May 2021 15:07:27 -0700
> > > >
> > > > Eli, could you link me to the merge_face_ref optimization discussion
> > > > so I could follow along please?
> > >
> > >   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41200
> >
> > Thank you. Wow, that seems to make a huge difference in typing latency feel.
>
> In "emacs -Q" as well?  If so, it again puzzles me how face merging
> has such a profound effect on redisplay in your case.  It shouldn't.

emacs -Q never really felt slow in terms of typing latency. In terms
of the scroll benchmark, I got:

w/o patch: 26.8s first run, 3.84s second run
w/ patch: 25.1s first run, 3.6s second run

With my emacs config that has, with everything loaded, 1156 faces, I get:

w/o patch: 18.6s on second run (at least 9s of which are attributed to
TAGGEDP and CONSP from lface_from_face_name_no_resolve)
w/ patch: 6.1s on second run

The impact is drastic.

One thing about my config is I eager load all of the packages I have
installed on idle, so I end up with all of their faces in my face
list. I don't have a massive config (147 packages, it looks like), but
it's apparently big enough.