Re: macOS metal rendering engine in mac port

[Eli Zaretskii <eliz@gnu.org>]

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

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

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

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

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

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

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

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