Re: macOS metal rendering engine in mac port

[Aaron Jensen <aaronjensen@gmail.com>]

On Sat, May 29, 2021 at 2:35 AM Alan Third <alan@idiocy.org> wrote:
>
> FWIW, on my Mac I put some timings into the display code and from the
> moment we receive a keyDown notification to the moment we hand off the
> drawn buffer to the system for display takes around 3-6ms, so unless
> Aaron's system is very different from mine, most of that time is spent
> in places we can't do much about.

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'm actually measuring using a high speed
camera (iphone) and comparing the physical keydown time, so it
includes keyboard controller time, USB signal time, OS interrupt
handling, monitor pixel latency, etc.

Oh and I was mistaken on my face count, that was actually the position
of the line-number face. My face count is 1234 at the moment.

On Sat, May 29, 2021 at 2:41 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> The question is: is this 3 to 6ms delay affected in any way by turning
> on line numbers?  If not, then not only don't I understand why line
> numbers affect the latency, I also don't understand how come the
> number of faces affects that.

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 specifically with faces that are very
late in my list of faces. This is a profile of me typing about 10
characters with the profile tree reversed and a lower debug symbol
setting (not sure what, i built this with homebrew) so it's not
showing macros:

https://cln.sh/9Fsiqe

If I slice that to only include calls from maybe_produce_line_number,
I get 203ms to assq_no_quit.

This means 37% of the CPU time emacs spends when I'm typing is in
assq_no_quit for face lookup.

It also means that 21% of the CPU time emacs spends when I'm typing is
in assq_no_quit for face lookup specifically for line numbers. So,
line numbers account for 57% of the CPU time spent doing face lookups
on my machine.

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?
I'm not sure I could answer that, but it's intuitive that the more
faces one has, the more time a machine would spend doing linear scans,
and when those scans are done a massive number of times, it's not
surprising to see them show up on profiles.

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

And with the patch:

(benchmark 500000 '(gethash 'line-number face--new-frame-defaults))

My config: 0.06s
emacs -Q: 0.06s

500k is roughly how many *extra* calls to
lface_from_face_name_no_resolve are made during the scroll up
benchmark when line numbers are enabled.

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.

Aaron

> --
> Alan Third