Re: macOS metal rendering engine in mac port

[Eli Zaretskii]

On May 25, 2021 7:42:45 AM GMT+03:00, Aaron Jensen <aaronjensen@gmail.com> 
wrote:
> 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)

What are you comparing?  When line numbers are off, maybe_produce_line_number 
shouldn't be called at all, and so shouldn't the merge_faces calls it makes.

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

That's a general problem with faces, which will hopefully be fixed soon.  
Nothing to do specifically with line-number display.

> Alan, I could understand why drawing glyphs would take longer (there's
> more to draw when there are line numbers),

??? Because line numbers add ~3 glyphs to each line?  How can this explain any 
significant slowdown?  Do you see something similar if you add 3 characters to 
every line and benchmark the scroll?