Re: macOS metal rendering engine in mac port

[Aaron Jensen]

On Mon, May 24, 2021 at 10:41 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > 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.

Line numbers off to line numbers on, which is why I didn't put a % on
the maybe_produce_line_number line. That is all added 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.
>
> That's a general problem with faces, which will hopefully be fixed soon.  
> Nothing to do specifically with line-number display.

That's great.

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

I added 3 characters to the end of every line of xdisp.c (//1) and it
went from 7.2s to 8.4s -- 17% (emacs -Q, no line numbers).

The timing differences are primarily in display_line. gui_write_glyphs
is 15% slower, which is nowhere near 576ms. Profile attached.

That certainly doesn't match the 78% slower for drawing glyphs in the
line number scenario.

Any suggestions on what to try next?

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