Re: macOS metal rendering engine in mac port

[Aaron Jensen <aaronjensen@gmail.com>]

On Sat, May 29, 2021 at 10:34 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > 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?)

It was with the patch. I was primarily reporting that for Alan's
benefit as he and I had been discussing those latency numbers.

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

I didn't, because I hadn't measured it yet. I just measured it and
it's very similar. This measurement technique is very imprecise, so I
have to take several measurements. I can't measure a difference
between line numbers and not when the hash patch is applied.

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

I did not say this. 500k times, according to the benchmarks I
provided, take over 2s. It's only 15ms to do 500k _hash lookups_.

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

My theme is set up like this:
https://github.com/aaronjensen/nano-emacs/blob/master/nano-theme.el

I don't know if I'm doing something wrong in there, I copied it from
the nano project. I know it's atypical to not use a theme.

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

Yes, a linear effect compounded by a large number of calls. That said,
it looks like the effect is 2x what I'd expect given the difference
between face counts. So yes, there may be something else at play. I'd
have to actually put a count in assq_no_quit to see if it's being
called more times than I'd expect.

About perceiving typing latency, have you read this article:
https://pavelfatin.com/typing-with-pleasure/

It's what finally helped me understand what I was perceiving many years ago.

Aaron