[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.
CleanShot 2021-05-24 at 08.59.53@2x.png
Description: PNG image
- Re: macOS metal rendering engine in mac port, (continued)
- Re: macOS metal rendering engine in mac port, Alan Third, 2021/05/25
- Re: macOS metal rendering engine in mac port, Aaron Jensen, 2021/05/25
- Re: macOS metal rendering engine in mac port, Eli Zaretskii, 2021/05/25
- Re: macOS metal rendering engine in mac port, Aaron Jensen, 2021/05/25
- Re: macOS metal rendering engine in mac port, Alan Third, 2021/05/25
- Re: macOS metal rendering engine in mac port, Eli Zaretskii, 2021/05/24
- Re: macOS metal rendering engine in mac port,
Aaron Jensen <=
- Re: macOS metal rendering engine in mac port, Alan Third, 2021/05/23
- Re: macOS metal rendering engine in mac port, Alan Third, 2021/05/23
- Re: macOS metal rendering engine in mac port, Alan Third, 2021/05/23
- Re: macOS metal rendering engine in mac port, Alan Third, 2021/05/23
- Re: macOS metal rendering engine in mac port, Aaron Jensen, 2021/05/23
- Re: macOS metal rendering engine in mac port, Alan Third, 2021/05/24
- Re: macOS metal rendering engine in mac port, Aaron Jensen, 2021/05/25
- Re: macOS metal rendering engine in mac port, Aaron Jensen, 2021/05/25
- Re: macOS metal rendering engine in mac port, Alan Third, 2021/05/26
- Re: macOS metal rendering engine in mac port, Aaron Jensen, 2021/05/26