Re: macOS metal rendering engine in mac port

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Sat, 29 May 2021 10:05:51 -0700
> Cc: Alan Third <alan@idiocy.org>, emacs-devel@gnu.org
> 
> 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.

I think we might be mis-communicating.  You said:

> Oh, and even with my config, with line numbers, in a ruby file, I'm
> seeing 60-80ms latency with my measuring app. That's quite a bit
> better.

(Was this with or without the hash patch applied?)

In response I asked:

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

I wanted to know the latency _without_ line numbers in the same setup
where with line numbers you see 60-80ms.  I'm not sure what you wrote
above answers that question.

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

Its being significant is what surprises me.  The linear search in
assq_no_quit should be very fast, as it requires just a few machine
instructions per member.  You yourself say your profile says it takes
15ms to call that function 500k times.  How can extra 15ms be so
significant?

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

I don't understand this.  I think there's some other factor at work
here.

Is it possible that many of the 1200 faces you have inherit from other
faces, perhaps recursively?

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

But if these faces are always at the same place near the end of the
list, then adding more faces should indeed produce a linear effect,
right?