Re: macOS metal rendering engine in mac port

[Eli Zaretskii <eliz@gnu.org>]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Sun, 23 May 2021 20:56:08 -0700
> Cc: Alan Third <alan@idiocy.org>, emacs-devel@gnu.org, 
> 	YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> 
> Here are some interesting profile pictures. On the left is emacs -Q w/
> display-line-numbers-mode. On the right is a partial version of my
> config with some of the things I mentioned before removed. Most of the
> difference between the two comes in the amount of time spent in
> merge_faces. My config ends up spending roughly 7.5x more time in
> merge_faces (1500ms vs 200ms). What causes that to get slower?

Some observations about these profiles:

First, given the non-repeatability of the benchmarks whose data you
exchanged with Alan, I'm not sure we should trust these profiles.

More importantly, look at the percentage: you are showing only a part
of the CPU usage.  In the case of the upper image, a relatively small
part: 17% in the left case, 27% in the right case.  The rest, which is
the bulk of the CPU usage, is under Fredisplay, and is not expanded,
so we don't see what takes most of the time there.  Suppose we reduce
the CPU usage of maybe_produce_line_number and merge_faces to zero:
that would still leave 70 to 80 percent of runtime.  So it's important
to look at the fully expanded profile.

The lower pair of profiles is even more puzzling.  Look at the
expansion of Fredisplay: it in effect tells me that try_window, a
function that redisplays a complete window, and its workhorse
display_line (which displays a full screen line) spend 100% of their
time inside maybe_produce_line_number, and the rest of their code
takes 0% of CPU!  This simply cannot be true, since display of the
line numbers is just a small part of what needs to be done for
redisplaying a window.

So I don't really understand how to interpret these profiles.

Thanks.