|
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
line-numbers-3.png
Description: PNG image
no-line-numbers-2.png
Description: PNG image
line-numbers-2.png
Description: PNG image
no-line-numbers-1.png
Description: PNG image
line-numbers-1.png
Description: PNG image
[Prev in Thread] | Current Thread | [Next in Thread] |