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 21:42:45 -0700

On Mon, May 24, 2021 at 7:31 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> No mystery: face merging is just a small fraction of what redisplay
> does, so the twofold increase in face merging shouldn't slow down
> redisplay too much.

Apple removed the text export feature of Instruments. Sigh. I've
attached screenshots of a much more expanded profile. It's not just
the merge_faces, it's slower in multiple places.

2060ms slower in total (40% slower):
444ms in maybe_produce_line_number, only 227ms of which is merge_faces
576ms more in drawing glyphs (78% slower)
490ms more copying surface contents (18% slower)

That leaves another 550ms scattered around as everything seems to be
slightly slower.

I'm not sure if there's some thermal thing going on that's making
everything slower, but instruments reports that thermal state was
normal the entire time.

With emacs -Q, the merge_faces tax isn't very high. It's just 10% of
the slowdown I saw in this benchmark. It's just that that tax scales
with the more faces I have, so it becomes a bigger chunk.

Alan, I could understand why drawing glyphs would take longer (there's
more to draw when there are line numbers), but does it make sense that
copying the surface contents would be slower? Is there compression or
is X bytes X bytes? I don't change my screen size between, so it
wouldn't make sense that they would vary that much.

Thanks,

Aaron

Attachment: line-numbers-3.png
Description: PNG image

Attachment: no-line-numbers-2.png
Description: PNG image

Attachment: line-numbers-2.png
Description: PNG image

Attachment: no-line-numbers-1.png
Description: PNG image

Attachment: line-numbers-1.png
Description: PNG image


reply via email to

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