Re: macOS metal rendering engine in mac port

[Aaron Jensen <aaronjensen@gmail.com>]

On Sat, May 29, 2021 at 9:49 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Aaron Jensen <aaronjensen@gmail.com>
> > Date: Sat, 29 May 2021 09:18:07 -0700
> >
> > On Sat, May 29, 2021 at 2:21 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > >
> > > Compared to what latency without line numbers?  60-80ms is quite a lot
> > > for redisplay, but I don't really have a clear picture of how that
> > > works on NS.
> >
> > Often around 90-100ms.
>
> I don't understand: you get 60-80ms _with_ line numbers and 90-100ms
> _without_ line numbers?  That's the opposite of what I would expect.

Ugh, my reading comprehension is off this morning. That was the
without _patch_ timing I shared. Turning off line numbers when the
patch is enabled likely won't make a difference. I can't measure that
right now.

> > As I've described earlier in this thread, turning on line numbers
> > massively increases the number of calls to
> > lface_from_face_name_no_resolve
>
> And as I've explained to you, "massively" is an exaggeration.  The
> number of face merges increases roughly two-fold when you turn on line
> numbers.

4.5x more calls to lface_from_face_name_no_resolve. Exaggeration or
not, it's significant.

> > specifically with faces that are very late in my list of faces.
>
> Which faces are those?  If they are line-number faces, does it mean
> that turning on display-line-numbers-mode earlier makes redisplay
> faster for you?

Yes, line number faces. You mean later so that they're nearer to the
head of the list? I'm not sure how to test that as the faces get added
even w/o enabling line number mode afaict. I also don't know how to
modify a frame's face alist and when I tried modifying
face-new-frame-defaults and creating a new frame it didn't appear to
make a difference.

> > If I slice that to only include calls from maybe_produce_line_number,
> > I get 203ms to assq_no_quit.
>
> Not sure I understand: 230ms for a _single_ call to assq_no_quit?  If
> not, for how many calls?

No. I don't know how many, but some multiple of 500k. I haven't added
a count printer in there yet.

> > This means 37% of the CPU time emacs spends when I'm typing is in
> > assq_no_quit for face lookup.
>
> 37% by itself is not a catastrophe.  Redisplay performs many face
> merges.

Well, it's worth mentioning that I'm being persnickety here. Most
people probably wouldn't notice the latency difference, but I can feel
it and it's frustrating. Here is a profile from a single key press
using my config w/o the patch:

https://cln.sh/HqVzJv

It's reversed, but you can see 15ms spent in assq_no_quit. For some
reason, that's enough to put it right over the edge of what I can feel
when I type.

> > So, perhaps the question is, why is assq_no_quit such a hot spot for
> > me on my machine when there are over 1000 faces in the list to scan?
>
> Good question.
>
> > Another data point, without the patch:
> >
> > (benchmark 500000 '(assoc 'line-number face-new-frame-defaults))
> >
> > On my emacs config: 2.7s
> > emacs -Q: 0.14s
>
> That's 5.4 microseconds per call.  How is this consistent with the
> 230ms figure above?

Because, as I mentioned below, 500k is the same number of times
lface_from_face_name_no_resolve is called, which is the thing that's
calling assq_no_quit.

> > And with the patch:
> >
> > (benchmark 500000 '(gethash 'line-number face--new-frame-defaults))
> >
> > My config: 0.06s
> > emacs -Q: 0.06s
>
> That's not surprising.  But what does it tell you about the actual use
> case which we were discussing?

It tells me that in the scroll benchmark I add over 2s to my time just
because of face merging and most of that time is due to enabling line
numbers.

> > I'm really not seeing anything mysterious about this, but I don't have
> > the context you have so I could be missing something. It looks like a
> > case of O(N) scales worse than O(log n). I just happen to have an N
> > that is 10x the N with emacs -Q.
>
> Linear search should be linear in the number of faces in the list.

Well, to be precise, it's linear in the position of the thing found,
which is relevant when most of the calls are for the same 2 elements.