emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: macOS metal rendering engine in mac port


From: Aaron Jensen
Subject: Re: macOS metal rendering engine in mac port
Date: Mon, 24 May 2021 09:10:17 -0700

On Mon, May 24, 2021 at 5:47 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> First, given the non-repeatability of the benchmarks whose data you
> exchanged with Alan, I'm not sure we should trust these profiles.

I'd have a hard time imagining I'm the only person that can reproduce
specifically the issue with emacs -Q and turning line numbers on. It
can't be a machine specific thing that's causing such an increase
merge_faces calls, could it?

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

Yes, I'm sorry. I was showing the most direct comparison for the point
I was trying to make, but I did not explain that well. I attached a
picture of the same two profiles as the first picture with some more
expanded in the top section (which also has
maybe_produce_line_number->merge_faces).

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

Again, my fault. I narrowed that profile to only showing callers of
merge_faces but did not communicate that. So that % is based only on
those things that call merge_faces.

If you could read the traces file I'd just send you those, but I'm
sure you don't have a modern mac sitting around with the most recent
xcode. I'll see if there's a text export if more clarity is needed.

Attachment: CleanShot 2021-05-24 at 08.59.53@2x.png
Description: PNG image


reply via email to

[Prev in Thread] Current Thread [Next in Thread]