macOS metal rendering engine in mac port

macOS metal rendering engine in mac port

[Aaron Jensen]

[-- Attachment #1: Type: text/plain, Size: 986 bytes --]

Hi,

I recently went from working entirely on my laptop screen to working on a
large 5k2k monitor on macOS with Emacs 28. When I made that move, when
Emacs was sized to take up 2/3rds of the monitor there was severe typing
lag. Enough that typing in it felt really frustrating. I realized that
shrinking the frame size helped alleviate the typing lag significantly.

Inspired by a recent reddit post, I decided to give the emacs macport a try
again with its metal rendering engine (--with-mac-metal). I'm pleasantly
surprised by its performance. It's very usable regardless of my window size.

I'm curious if now might be a good time to consider bringing over at least
this rendering engine from the mac port and making it a part of Emacs
proper. I'm not familiar with all of the reasons for keeping the mac port
separate so maybe this whole thing is a non-starter, but I wanted to raise
it because it's a real quality of life improvement on larger/higher dpi
screens.

Thanks,


Aaron

[-- Attachment #2: Type: text/html, Size: 1338 bytes --]

Re: macOS metal rendering engine in mac port

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Thu, 20 May 2021 18:17:18 -0700
> Cc: Alan Third <alan@idiocy.org>,
>  YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> 
> Inspired by a recent reddit post, I decided to give the emacs macport a try again with its metal rendering
> engine (--with-mac-metal). I'm pleasantly surprised by its performance. It's very usable regardless of my
> window size.
> 
> I'm curious if now might be a good time to consider bringing over at least this rendering engine from the mac
> port and making it a part of Emacs proper. I'm not familiar with all of the reasons for keeping the mac port
> separate so maybe this whole thing is a non-starter, but I wanted to raise it because it's a real quality of life
> improvement on larger/higher dpi screens.

What is the "metal rendering engine", and where can one study what it
does?

Re: macOS metal rendering engine in mac port

[Aaron Jensen]

On Thu, May 20, 2021 at 11:07 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> What is the "metal rendering engine", and where can one study what it
> does?

Metal is Apple's new OpenGL like framework: https://developer.apple.com/metal/

There's lots of stuff to study there and a web search would turn up lots more.

The mac port has code mixed in macappkit.m under the HAVE_MAC_METAL
pragma var: https://bitbucket.org/mituharu/emacs-mac/src/master/src/macappkit.m

Re: macOS metal rendering engine in mac port

[Alan Third]

On Thu, May 20, 2021 at 06:17:18PM -0700, Aaron Jensen wrote:
> Hi,
> 
> I recently went from working entirely on my laptop screen to working on a
> large 5k2k monitor on macOS with Emacs 28. When I made that move, when
> Emacs was sized to take up 2/3rds of the monitor there was severe typing
> lag. Enough that typing in it felt really frustrating. I realized that
> shrinking the frame size helped alleviate the typing lag significantly.
> 
> Inspired by a recent reddit post, I decided to give the emacs macport a try
> again with its metal rendering engine (--with-mac-metal). I'm pleasantly
> surprised by its performance. It's very usable regardless of my window size.

Out of interest, is it the metal renderer making the difference, or is
the Mac port just better anyway?

I only ask because on my Mac enabling metal rendering results in a
*much* lower frame rate (although whether that equates to higher input
lag I don't know).

> I'm curious if now might be a good time to consider bringing over at least
> this rendering engine from the mac port and making it a part of Emacs
> proper. I'm not familiar with all of the reasons for keeping the mac port
> separate so maybe this whole thing is a non-starter, but I wanted to raise
> it because it's a real quality of life improvement on larger/higher dpi
> screens.

At that level the two ports don't really look alike, so it's not like
it's just a case of copying the relevant code over.

What might be helpful is to profile to find out what's slowing the NS
port down.
-- 
Alan Third

Re: macOS metal rendering engine in mac port

[Aaron Jensen]

On Fri, May 21, 2021 at 12:35 AM Alan Third <alan@idiocy.org> wrote:
>
> Out of interest, is it the metal renderer making the difference, or is
> the Mac port just better anyway?
>
> I only ask because on my Mac enabling metal rendering results in a
> *much* lower frame rate (although whether that equates to higher input
> lag I don't know).

Pressing and holding a key for 10s with a high key repeat rate:

Large frame:

NS: 300 letters input
Macport: 530 letters input
Macport with metal: 515 letters input

Smaller frame:

NS: 583 letters input
Macport: 599 letters input
Macport with metal: 595 letters input



Scrolling one line at a time with a high key repeat rate:

Large frame:

NS: 187 lines scrolled
Macport: 248 lines scrolled
Macport with metal: 171 lines scrolled

Smaller frame:

NS: 399 lines scrolled
Macport: 456 lines scrolled
Macport with meta: 338 lines scrolled

So yes, it appears that the macport without metal is actually faster
on my machine which is surprising.

How do you typically measure framerate?

That said, I have an app on my phone called "Is it snappy" that uses
the high speed camera to attempt to measure input latency. With my
full config measuring the input latency I get:

Large frame:

NS: 95.8 100.0 107.9 (101.2 ms avg)
Macport: 100.0 95.4 95.8 (97.1 ms avg)
Macport with Metal: 78.7 87.5 99.6 (88.6 ms avg)

Smaller frame (only one trial of each of these):

NS: 82.9 ms
Macport: 87.5 ms
Metal: 70.8 ms

>
> > I'm curious if now might be a good time to consider bringing over at least
> > this rendering engine from the mac port and making it a part of Emacs
> > proper. I'm not familiar with all of the reasons for keeping the mac port
> > separate so maybe this whole thing is a non-starter, but I wanted to raise
> > it because it's a real quality of life improvement on larger/higher dpi
> > screens.
>
> At that level the two ports don't really look alike, so it's not like
> it's just a case of copying the relevant code over.
>
> What might be helpful is to profile to find out what's slowing the NS
> port down.

Can I profile with XCode? What debug optimization level do I have to
use to make it useful?

Aaron

Re: macOS metal rendering engine in mac port

[Alan Third]

On Fri, May 21, 2021 at 08:27:14AM -0700, Aaron Jensen wrote:
> On Fri, May 21, 2021 at 12:35 AM Alan Third <alan@idiocy.org> wrote:
> >
> > Out of interest, is it the metal renderer making the difference, or is
> > the Mac port just better anyway?
> >
> > I only ask because on my Mac enabling metal rendering results in a
> > *much* lower frame rate (although whether that equates to higher input
> > lag I don't know).

Thanks for this.

> Pressing and holding a key for 10s with a high key repeat rate:
> 
> Large frame:
> 
> NS: 300 letters input
> Macport: 530 letters input
> Macport with metal: 515 letters input

That is quite a dramatic difference!

> So yes, it appears that the macport without metal is actually faster
> on my machine which is surprising.

I believe this is why it's no longer the default. All the shouting was
when it was disabled and people didn't read the note and thought it
was new.

> How do you typically measure framerate?

With this code that I nabbed from in here:

     (defun scroll-up-benchmark ()
       (interactive)
       (let ((oldgc gcs-done)
             (oldtime (float-time)))
         (condition-case nil (while t (scroll-up) (redisplay))
           (error (message "GCs: %d Elapsed time: %f seconds"
                           (- gcs-done oldgc) (- (float-time) oldtime))))))

> That said, I have an app on my phone called "Is it snappy" that uses
> the high speed camera to attempt to measure input latency. With my
> full config measuring the input latency I get:
> 
> Large frame:
> 
> NS: 95.8 100.0 107.9 (101.2 ms avg)
> Macport: 100.0 95.4 95.8 (97.1 ms avg)
> Macport with Metal: 78.7 87.5 99.6 (88.6 ms avg)

This is quite interesting! It looks like metal reduces the total
throughput, but speeds up the time it take to actually get the image
to the screen. I wonder why that is...?

> > What might be helpful is to profile to find out what's slowing the NS
> > port down.
> 
> Can I profile with XCode? What debug optimization level do I have to
> use to make it useful?

Yes, and I don't think you need to do anything special with
optimisation levels.

Load instruments.app, choose "time profiler", then at the top select
emacs and hit the record button. Do whatever you do, then hit the stop
button, and the window below should give some indication of where it
is spending the most time. I was thinking that it would be in the copy
from one surface to the other, but I profiled my own build and it
appears to be negligible. OTOH, since your surfaces are much bigger
that might be it.

I've tried reducing the amount of times the NS port updates the
screen, although I don't think I've really been very successful, but
you may as well give it a go and see if it makes any difference.
Please try the scratch/ns/surface-stuff branch.

And for a laugh try this patch on top of that branch. It's not
suitable for general use, but it seems a bit faster here.

modified   src/nsterm.m
@@ -8516,6 +8516,7 @@ - (void)updateLayer
      could use to force it, but we shouldn't often get the same
      surface twice in a row.  */
   [[self layer] setContents:(id)[surface getSurface]];
+  [[self layer] setContentsChanged];
 }
 #endif
 
@@ -9716,7 +9717,7 @@ @implementation EmacsSurface
    probably be some sort of pruning job that removes excess
    surfaces.  */
 
-#define CACHE_MAX_SIZE 2
+#define CACHE_MAX_SIZE 1
 
 - (id) initWithSize: (NSSize)s
          ColorSpace: (CGColorSpaceRef)cs

If that doesn't help with the lag then I think I've only got one other
thing to try before trying to implement 3D rendering. ;)
-- 
Alan Third

Re: macOS metal rendering engine in mac port

[Aaron Jensen]

While profiling this, many signs point to line number display being a
hot spot when display-line-numbers-mode is enabled. Specifically,
maybe_produce_line_number calling merge_faces. Ultimately, most of the
time is spent in TAGGEDP which is called by CONSP in assq_no_quit.

Here's a reverse tree: https://cln.sh/nLrew6

Is there anything that can be done for caching the merged face? Surely
it doesn't change in a tight loop, but maybe I'm misunderstanding the
code.

Thanks,

Aaron

Re: macOS metal rendering engine in mac port

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Sat, 22 May 2021 09:01:03 -0700
> 
> While profiling this, many signs point to line number display being a
> hot spot when display-line-numbers-mode is enabled. Specifically,
> maybe_produce_line_number calling merge_faces. Ultimately, most of the
> time is spent in TAGGEDP which is called by CONSP in assq_no_quit.
> 
> Here's a reverse tree: https://cln.sh/nLrew6

This profile is shown in reverse, so it's hard to interpret it.  Are
the numbers cumulative, or are they self-percents?  If the latter, I
cannot understand why CONSP is such a hot spot, it sounds improbable.

Did you customize the line-number face? if so, what happens if you
don't?  If you didn't customize the face, I don't think I understand
why we need to spend so much time in face-merging.  Or maybe you have
a lot of faces defined?

Also, if you run the scroll-benchmark with and without line numbers,
how much do the results differ?

> Is there anything that can be done for caching the merged face?

Emacs always caches every face it realizes, so that is already done.
Unless you have some Lisp hooks that somehow invalidate the face
cache, what you see is with the face cache being used.

Anyway, what you see sounds strange.  When I added
display-line-numbers, I measured the effect on redisplay and found it
negligible.  About the only situation where it was tangible was with
visual-mode line numbers, and even then the slowdown was around 10%.
So I don't know how to explain what you perceive as significant
slowdown.

Re: macOS metal rendering engine in mac port

[Eli Zaretskii]

> Date: Sat, 22 May 2021 19:30:24 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: alan@idiocy.org, mituharu@math.s.chiba-u.ac.jp, emacs-devel@gnu.org
> 
> Did you customize the line-number face? if so, what happens if you
> don't?  If you didn't customize the face, I don't think I understand
> why we need to spend so much time in face-merging.  Or maybe you have
> a lot of faces defined?

One other question: do you have the line-number-ticks enabled?

Re: macOS metal rendering engine in mac port

[Eli Zaretskii]

I just now ran the scroll-benchmark on xdisp.c in "emacs -Q" of the
latest master: the results with line-numbers turned on are just 2.5%
slower than without line numbers.

Re: macOS metal rendering engine in mac port

[Alan Third]

On Fri, May 21, 2021 at 04:02:07PM -0700, Aaron Jensen wrote:
> On Fri, May 21, 2021 at 10:39 AM Alan Third <alan@idiocy.org> wrote:
> >
> > Yes, and I don't think you need to do anything special with
> > optimisation levels.
> >
> > Load instruments.app, choose "time profiler", then at the top select
> > emacs and hit the record button. Do whatever you do, then hit the stop
> > button, and the window below should give some indication of where it
> > is spending the most time. I was thinking that it would be in the copy
> > from one surface to the other, but I profiled my own build and it
> > appears to be negligible. OTOH, since your surfaces are much bigger
> > that might be it.
> >
> > I've tried reducing the amount of times the NS port updates the
> > screen, although I don't think I've really been very successful, but
> > you may as well give it a go and see if it makes any difference.
> > Please try the scratch/ns/surface-stuff branch.
> 
> I got 378 characters on this branch, which is a little faster.
> I should also note that on Emacs 27 NS I get 578 characters, which is
> slightly faster than Emacs mac port.

On my machine the scroll benchmark shows Emacs 27 being able to update
the screen more than twice as fast as any version of the Mac port, yet
this shows Emacs 27 isn't really any better.

Perhaps they both reach the maximum input rate?

Or the NS port's event handling is slow, which is quite possible as
it's single threaded and I think the Mac port uses a separate thread
for toolkit stuff. (Someone please correct me if I'm wrong.)

IIRC you said that you still thought input in Emacs 27 feels sluggish?

> I've attached a couple profiles of the surface stuff branch.

It turns out I can't open these because my version of xcode is too
old... Although I think it's the most recent I can use on this
machine.

> Of note is that display-line-number-mode seems to be a massive
> culprit in slowing this down. Turning that off about gives me about
> 50% more performance.

Does it give a similar slowdown in the Mac port?

> The rest of what takes time appears to be mem copies, which makes
> sense that that would scale w/ screen size.

If someone wanted to send me a 5k screen, debugging this would be a
lot easier. ;)
-- 
Alan Third

Re: macOS metal rendering engine in mac port

[Aaron Jensen]

On Sat, May 22, 2021 at 11:45 AM Alan Third <alan@idiocy.org> wrote:
>
> On my machine the scroll benchmark shows Emacs 27 being able to update
> the screen more than twice as fast as any version of the Mac port, yet
> this shows Emacs 27 isn't really any better.

For some reason, Emacs Mac port (non-metal) doesn't paint the screen
during scroll-up-benchmark, it just pauses, but it's faster on my
machine.

Full screen frame, with line numbers (11k lines):

Mac port: 2.88s
emacs27-drawing branch: 4.42s
master: 6.75s

Full screen frame, no line numbers (11k lines):

Mac port 2.24s
emacs27-drawing branch: 3.13s
master: 5.3s

>
> Perhaps they both reach the maximum input rate?
>
> Or the NS port's event handling is slow, which is quite possible as
> it's single threaded and I think the Mac port uses a separate thread
> for toolkit stuff. (Someone please correct me if I'm wrong.)

Ah that might explain why things feel a little faster, especially w/
company-mode.

> IIRC you said that you still thought input in Emacs 27 feels sluggish?
>
> > I've attached a couple profiles of the surface stuff branch.
>
> It turns out I can't open these because my version of xcode is too
> old... Although I think it's the most recent I can use on this
> machine.

Doh. I'll send screenshots next time.

> > Of note is that display-line-number-mode seems to be a massive
> > culprit in slowing this down. Turning that off about gives me about
> > 50% more performance.
>
> Does it give a similar slowdown in the Mac port?

Not quite as significant. And on the scrolling benchmark, it's not
50%, but it is 25-40%

> > The rest of what takes time appears to be mem copies, which makes
> > sense that that would scale w/ screen size.
>
> If someone wanted to send me a 5k screen, debugging this would be a
> lot easier. ;)

I may be selling mine in time... Is it possible to set your resolution
to higher than your monitor supports and scale it down? Also, maybe
decreasing your font size may change things as there'd be more lines.

Aaron

Re: macOS metal rendering engine in mac port

[Alan Third]

On Sat, May 22, 2021 at 11:59:43AM -0700, Aaron Jensen wrote:
> On Sat, May 22, 2021 at 11:45 AM Alan Third <alan@idiocy.org> wrote:
> >
> > On my machine the scroll benchmark shows Emacs 27 being able to update
> > the screen more than twice as fast as any version of the Mac port, yet
> > this shows Emacs 27 isn't really any better.
> 
> For some reason, Emacs Mac port (non-metal) doesn't paint the screen
> during scroll-up-benchmark, it just pauses, but it's faster on my
> machine.

Well, I'm sure we can make that optimisation on the NS port too. ;)

> Full screen frame, with line numbers (11k lines):
> 
> Mac port: 2.88s
> emacs27-drawing branch: 4.42s
> master: 6.75s
> 
> Full screen frame, no line numbers (11k lines):
> 
> Mac port 2.24s
> emacs27-drawing branch: 3.13s
> master: 5.3s

How can the Mac port only see a change of 0.6s while the NS port sees
a change of 1.3s, when the only change is turning line numbers on or
off? Line numbers performance should surely be mostly independent of
the UI toolkit?

You know, my benchmarking is all over the place. I literally just did
two runs at 11s and another two at 8.6s. Nothing changed. And I
regularly see a code change produce an improvement, then undoing the
change retaining the improvement. It's like rebuilding the exact same
code base produces a completely different performance result.

I suspect my Mac rides the CPU frequency continuously or something.
-- 
Alan Third

Re: macOS metal rendering engine in mac port

[Aaron Jensen]

On Sat, May 22, 2021 at 12:57 PM Alan Third <alan@idiocy.org> wrote:
>
> Well, I'm sure we can make that optimisation on the NS port too. ;)

Hah

> > Full screen frame, with line numbers (11k lines):
> >
> > Mac port: 2.88s
> > emacs27-drawing branch: 4.42s
> > master: 6.75s
> >
> > Full screen frame, no line numbers (11k lines):
> >
> > Mac port 2.24s
> > emacs27-drawing branch: 3.13s
> > master: 5.3s
>
> How can the Mac port only see a change of 0.6s while the NS port sees
> a change of 1.3s, when the only change is turning line numbers on or
> off? Line numbers performance should surely be mostly independent of
> the UI toolkit?

No idea. It seems to be percentage based more than fixed for whatever
reason. I built emacs 27 w/ -g3 -O2

> You know, my benchmarking is all over the place. I literally just did
> two runs at 11s and another two at 8.6s. Nothing changed. And I
> regularly see a code change produce an improvement, then undoing the
> change retaining the improvement. It's like rebuilding the exact same
> code base produces a completely different performance result.
>
> I suspect my Mac rides the CPU frequency continuously or something.

Mine are fairly consistent. I imagine hitting thermal would hurt
though and Intel macs love to do that.

What isn't consistent is typing experience. There are times when it's
just like molasses but I can't necessarily reproduce that with
benchmarks. I wonder if the separate threaded IO from the mac port
helps make things feel more consistent in some way.

It'd be great to try an emacs-28 with the 27+flicker patch rendering.
I'd be curious how that'd feel w/ native comp. Maybe that'd make
enough of a difference for me on this screen.

Thanks,

Aaron

Re: macOS metal rendering engine in mac port

[Alan Third]

On Sat, May 22, 2021 at 02:20:34PM -0700, Aaron Jensen wrote:
> > How can the Mac port only see a change of 0.6s while the NS port sees
> > a change of 1.3s, when the only change is turning line numbers on or
> > off? Line numbers performance should surely be mostly independent of
> > the UI toolkit?
> 
> No idea. It seems to be percentage based more than fixed for whatever
> reason. I built emacs 27 w/ -g3 -O2

Me too. I checked the Mac port flags too in case it was doing
something sneaky, but nope, looks the same.

> > You know, my benchmarking is all over the place. I literally just did
> > two runs at 11s and another two at 8.6s. Nothing changed. And I
> > regularly see a code change produce an improvement, then undoing the
> > change retaining the improvement. It's like rebuilding the exact same
> > code base produces a completely different performance result.
> >
> > I suspect my Mac rides the CPU frequency continuously or something.
> 
> Mine are fairly consistent. I imagine hitting thermal would hurt
> though and Intel macs love to do that.

Yeah, I wonder if that's what's happening. I have to say that I don't
think this Mac has ever been what I'd consider fast. My ancient first
gen i7 absolutely wipes the floor with it in compilation speed
despite being at least 7 years older. I guess Moores law really did
run out of steam. ;)

> What isn't consistent is typing experience. There are times when it's
> just like molasses but I can't necessarily reproduce that with
> benchmarks. I wonder if the separate threaded IO from the mac port
> helps make things feel more consistent in some way.

Probably, the threading also seems to be used to do the buffer copies
and things. AFAICT it also offloads the copy to Metal when it's
enabled, although I imagine that then involves copying the buffer back
down to system RAM from VRAM for updating, so I don't know how much of
a win it really is. On a fast graphics card it maybe really is a big
win.

> It'd be great to try an emacs-28 with the 27+flicker patch rendering.
> I'd be curious how that'd feel w/ native comp. Maybe that'd make
> enough of a difference for me on this screen.

It's a lot of work. I'd have to be sure that the patch actually stops
the flashing and blanking before I tried that. I'm not hopeful, tbh.

Anyway, the last thing I want to try to improve lag is to move the
buffer copy to as soon after the layer update as possible, so that
when you hit a key we don't have to wait for it before we can start
drawing. I've pushed a change to the surface-stuff branch, so can you
please give it a go and see if there's any improvement.
-- 
Alan Third

Re: macOS metal rendering engine in mac port

[Stefan Monnier]

>> Mine are fairly consistent. I imagine hitting thermal would hurt
>> though and Intel macs love to do that.
>
> Yeah, I wonder if that's what's happening. I have to say that I don't
> think this Mac has ever been what I'd consider fast. My ancient first
> gen i7 absolutely wipes the floor with it in compilation speed
> despite being at least 7 years older. I guess Moores law really did
> run out of steam. ;)

Dennard scaling and Moore's law both ran out of steam, indeed.
For many modern machines there is a very large difference between the
peak single thread performance attainable in a short sprint and the
sustainable single thread performance, and yet more difference with the
sustainable performance of single thread running while other threads are
also running.
E.g. my Librem mini's "top speed" in GHz can vary between 4.7GHz
and 1.8GHz depending on those circumstances.

So, when I need stable results to compare the speed for 2 different
operations, I generally do it as follows:

- Write a script that runs A enough times for the duration to be in
  the "seconds" range.  Same for B.  Make that script print the
  time measurement.
- Write a loop whose body runs A followed by B.
- Run that loop and look at the measurements.

Then you should see that the measurements will stabilize as the thermal
constraints stabilize (of course, you'll also want to avoid other
activity on the machine during that time, as usual).

Of course, that doesn't guarantee that what you measure is
representative of what the user will see, but least it lets you compare
apples to apples.


        Stefan

Re: macOS metal rendering engine in mac port

[Aaron Jensen]

On Sun, May 23, 2021 at 4:47 AM Alan Third <alan@idiocy.org> wrote:
> >
> > Mine are fairly consistent. I imagine hitting thermal would hurt
> > though and Intel macs love to do that.
>
> Yeah, I wonder if that's what's happening. I have to say that I don't
> think this Mac has ever been what I'd consider fast. My ancient first
> gen i7 absolutely wipes the floor with it in compilation speed
> despite being at least 7 years older. I guess Moores law really did
> run out of steam. ;)

I'm curious what chip you have? I have a 2.4 GHz I9-9980HK and it's
not slow to compile, but the linux machine I was using for a while
demolished it. Of course, that was a 16 core 3950X, so...

> > What isn't consistent is typing experience. There are times when it's
> > just like molasses but I can't necessarily reproduce that with
> > benchmarks. I wonder if the separate threaded IO from the mac port
> > helps make things feel more consistent in some way.
>
> Probably, the threading also seems to be used to do the buffer copies
> and things. AFAICT it also offloads the copy to Metal when it's
> enabled, although I imagine that then involves copying the buffer back
> down to system RAM from VRAM for updating, so I don't know how much of
> a win it really is. On a fast graphics card it maybe really is a big
> win.

Interesting. And generally speaking, are there licensing issues
preventing a merge/collaboration w/ the mac port?

> It's a lot of work. I'd have to be sure that the patch actually stops
> the flashing and blanking before I tried that. I'm not hopeful, tbh.

I've been using it and haven't seen any flickers. I'll continue using
it and report back. I probably would have seen one by now.

> Anyway, the last thing I want to try to improve lag is to move the
> buffer copy to as soon after the layer update as possible, so that
> when you hit a key we don't have to wait for it before we can start
> drawing. I've pushed a change to the surface-stuff branch, so can you
> please give it a go and see if there's any improvement.

Will do.

Re: macOS metal rendering engine in mac port

[Aaron Jensen]

On Sun, May 23, 2021 at 9:13 AM Aaron Jensen <aaronjensen@gmail.com> wrote:
>
> I've been using it and haven't seen any flickers. I'll continue using
> it and report back. I probably would have seen one by now.

So one important note, I'm selling my 5k2k giant monitor so it's boxed
up (if anyone is interested, email me :) ). I'm on a 24" 4k monitor
now running at 1920x1080 scaled, whereas before I was at 3008x1269.

So, this morning when I run the scroll-up-benchmark it does what the
macport did. That is, it looks like it hangs for a second, shows maybe
1 or two scrolls and then jumps to the bottom.

I get roughly 2.3s w/ line numbers and 1.16 without.

On the new surface-stuff branch, I get 4.7s w/ line numbers and 2.98s w/o.

And for Eli, just to be sure it's not my theme causing issues w/ line
numbers on Emacs 28 here's a comparison using the default Emacs theme:
5.45s w/ line numbers and 3.97s w/o

It's slower than my theme likely because my theme includes a much more
minimal mode-line (actually, it's a header-line with a nil mode-line).

Holding a letter test (line numbers on):

Emacs 27 rendering: 601 593 604 (avg 599)
Emacs 28 surface stuff branch: 589 595 595 (avg 593)

Those are likely just actually hitting the cap of my repeat rate and
the variation is because I'm just watching a stopwatch for the test.

Holding next line (line numbers on):

Emacs 27 rendering: 568 576 (avg 572)
Emacs 28 surface stuff branch: 378 386 (avg 382)

27 just about keeps up w/ key repeat rate I believe, whereas 28 is slower.

Just in terms of typing, I can't say I can feel a difference between
the two. They feel similar from my limited time typing on this
monitor.

Aaron

Re: macOS metal rendering engine in mac port

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Sun, 23 May 2021 10:06:35 -0700
> 
> And for Eli, just to be sure it's not my theme causing issues w/ line
> numbers on Emacs 28 here's a comparison using the default Emacs theme:
> 5.45s w/ line numbers and 3.97s w/o

Is this in "emacs -Q"?  And which file and in what major mode did you
scroll through?

Re: macOS metal rendering engine in mac port

[Aaron Jensen]

On Sun, May 23, 2021 at 10:21 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Aaron Jensen <aaronjensen@gmail.com>
> > Date: Sun, 23 May 2021 10:06:35 -0700
> >
> > And for Eli, just to be sure it's not my theme causing issues w/ line
> > numbers on Emacs 28 here's a comparison using the default Emacs theme:
> > 5.45s w/ line numbers and 3.97s w/o
>
> Is this in "emacs -Q"?  And which file and in what major mode did you
> scroll through?

No, it was in my config. In emacs -Q the difference isn't as stark and
it's quite a bit faster which has me wondering what the heck in my
config could slow things down that much.

line numbers: 1.54s
no line numbers: 1.37s

Only 12% difference there, which is still something but not the 30% I
was seeing on my config.

The file is a private ruby file that's copy pasted enough times to
make it 11k lines long. I was using enh-ruby-mode with my config but
regular ruby-mode doesn't make any difference.

I'll see if I can track down what makes such a big difference in my config.

Re: macOS metal rendering engine in mac port

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Sun, 23 May 2021 11:38:22 -0700
> Cc: Alan Third <alan@idiocy.org>, emacs-devel@gnu.org, 
> 	YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> 
> > Is this in "emacs -Q"?  And which file and in what major mode did you
> > scroll through?
> 
> No, it was in my config. In emacs -Q the difference isn't as stark and
> it's quite a bit faster which has me wondering what the heck in my
> config could slow things down that much.
> 
> line numbers: 1.54s
> no line numbers: 1.37s

Still too much.  What mode of display-line-numbers do you use? is it
the default or something else?

> The file is a private ruby file that's copy pasted enough times to
> make it 11k lines long. I was using enh-ruby-mode with my config but
> regular ruby-mode doesn't make any difference.

Try with xdisp.c, that's what I was using.

Re: macOS metal rendering engine in mac port

[Aaron Jensen]

On Sun, May 23, 2021 at 11:49 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Aaron Jensen <aaronjensen@gmail.com>
> > Date: Sun, 23 May 2021 11:38:22 -0700
> > Cc: Alan Third <alan@idiocy.org>, emacs-devel@gnu.org,
> >       YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> >
> > > Is this in "emacs -Q"?  And which file and in what major mode did you
> > > scroll through?
> >
> > No, it was in my config. In emacs -Q the difference isn't as stark and
> > it's quite a bit faster which has me wondering what the heck in my
> > config could slow things down that much.
> >
> > line numbers: 1.54s
> > no line numbers: 1.37s
>
> Still too much.  What mode of display-line-numbers do you use? is it
> the default or something else?

Default, just M-x display-line-numbers

> > The file is a private ruby file that's copy pasted enough times to
> > make it 11k lines long. I was using enh-ruby-mode with my config but
> > regular ruby-mode doesn't make any difference.
>
> Try with xdisp.c, that's what I was using.

Sure, in emacs -Q:

No line numbers: 4.27s
Line numbers: 5.78s

Re: macOS metal rendering engine in mac port

[Aaron Jensen]

On Sun, May 23, 2021 at 11:38 AM Aaron Jensen <aaronjensen@gmail.com> wrote:
>
> I'll see if I can track down what makes such a big difference in my config.

Hi Eli,

Okay, so something interesting is going on here. It appears that
performance on the scroll benchmark degrades as I load more packages.

For example, with emacs -Q if I run the benchmark on xdisp.c I get
3.4s (no line numbers). If I then open an org file and require
org/start org-mode, then kill that buffer and go back to xdisp.c I get
at best 4.15s. That's a pretty big difference for just having loaded
org, I think.

Is that expected?

Some other things I've found, starting at 11.98s w/ my config:

Disabling my theme: 10.95s
Disabling GCMH (I know you don't recommend this anyway, but it's
helped with some stutters): 8.55
Reverting to default font: 8.24

Re: macOS metal rendering engine in mac port

[Aaron Jensen]

On Sun, May 23, 2021 at 5:00 PM Aaron Jensen <aaronjensen@gmail.com> wrote:
>
> On Sun, May 23, 2021 at 11:38 AM Aaron Jensen <aaronjensen@gmail.com> wrote:
> >
> > I'll see if I can track down what makes such a big difference in my config.
>
> Hi Eli,
>
> Okay, so something interesting is going on here. It appears that
> performance on the scroll benchmark degrades as I load more packages.
>
> For example, with emacs -Q if I run the benchmark on xdisp.c I get
> 3.4s (no line numbers). If I then open an org file and require
> org/start org-mode, then kill that buffer and go back to xdisp.c I get
> at best 4.15s. That's a pretty big difference for just having loaded
> org, I think.

Ugh, actually I can't reproduce this anymore in emacs -Q, sorry for
the noise. I definitely see it in my own config -- as I remove org
related packages and configuration things speed up, but I've got to do
more work to narrow it down further to exactly what it is. Removing
all of my org related configuration dropped me from 7.57s to 5.3s in
the xdisp.c test... which obviously isn't an org file, so something
odd is still going on.

Re: macOS metal rendering engine in mac port

[Aaron Jensen]

On Sun, May 23, 2021 at 8:56 PM Aaron Jensen <aaronjensen@gmail.com> wrote:
>
> Here are some interesting profile pictures. On the left is emacs -Q w/
> display-line-numbers-mode. On the right is a partial version of my
> config with some of the things I mentioned before removed. Most of the
> difference between the two comes in the amount of time spent in
> merge_faces. My config ends up spending roughly 7.5x more time in
> merge_faces (1500ms vs 200ms). What causes that to get slower?

One thing of note is that emacs -Q has 129 faces for me. My config has
anywhere from 600-800 faces depending on what's loaded it looks like.
lface_from_face_name_no_resolve does a linear time search for a face
every time it's called. It's called over 700k times when I do my
xdisp.c scroll up test. merge_faces is called over 150k times, each
time with line-number-current-line or line-number and 0's for face_id
and base_face_id. I don't really know what this code is doing at all,
but all of this seems suspect. Thoughts?

Re: macOS metal rendering engine in mac port

[Eli Zaretskii]

On May 24, 2021 9:51:42 AM GMT+03:00, Aaron Jensen <aaronjensen@gmail.com> wrote:
> On Sun, May 23, 2021 at 8:56 PM Aaron Jensen <aaronjensen@gmail.com>
> wrote:
> >
> > Here are some interesting profile pictures. On the left is emacs -Q
> w/
> > display-line-numbers-mode. On the right is a partial version of my
> > config with some of the things I mentioned before removed. Most of
> the
> > difference between the two comes in the amount of time spent in
> > merge_faces. My config ends up spending roughly 7.5x more time in
> > merge_faces (1500ms vs 200ms). What causes that to get slower?
> 
> One thing of note is that emacs -Q has 129 faces for me. My config has
> anywhere from 600-800 faces depending on what's loaded it looks like.
> lface_from_face_name_no_resolve does a linear time search for a face
> every time it's called. It's called over 700k times when I do my
> xdisp.c scroll up test. merge_faces is called over 150k times, each
> time with line-number-current-line or line-number and 0's for face_id
> and base_face_id. I don't really know what this code is doing at all,
> but all of this seems suspect. Thoughts?

Why does it look suspect to you?  Don't you also see the same code called to process the other faces in the buffer?

An Emacs face that is identified by name needs to be converted to the collection of the face's attributes, so that Emacs could merge faces and display them.  This is what lface_from_face_name does.  And it does that for any face specified in the buffer by its symbol.  So how come addition of just one face and a few characters which have that face have such a profound effect in your case?

Re: macOS metal rendering engine in mac port

[Aaron Jensen]

On Mon, May 24, 2021 at 12:37 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> Why does it look suspect to you?  Don't you also see the same code called to process the other faces in the buffer?

What looks suspect is that the exact same call is made so many times
for the exact same faces and that call gets slower proportional to the
number of faces you have because of the linear search. Fewer faces ==
less work, and when something is called so many times it may be worth
further optimization or caching.

> An Emacs face that is identified by name needs to be converted to the collection of the face's attributes, so that Emacs could merge faces and display them.  This is what lface_from_face_name does.  And it does that for any face specified in the buffer by its symbol.  So how come addition of just one face and a few characters which have that face have such a profound effect in your case?

I'm not sure I track your last question. In my case it's the addition
of 400-600 faces, none of which are used in the buffer. They just
exist in the alist that lface_from_face_name_no_resolve scans with
assq_no_quit. This is why TAGGEDP via CONSP is a hotspot in my code,
because it's called 600 * 700k (or some multiple thereof) times or so.
assq_no_quit via merge_faces accounts for 1.43s of 6.94s in one of my
profiles.

Re: macOS metal rendering engine in mac port

[Eli Zaretskii]

On May 24, 2021 11:07:42 AM GMT+03:00, Aaron Jensen <aaronjensen@gmail.com> wrote:
> On Mon, May 24, 2021 at 12:37 AM Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > Why does it look suspect to you?  Don't you also see the same code
> called to process the other faces in the buffer?
> 
> What looks suspect is that the exact same call is made so many times
> for the exact same faces and that call gets slower proportional to the
> number of faces you have because of the linear search. Fewer faces ==
> less work, and when something is called so many times it may be worth
> further optimization or caching.

But we do the same for every face in the buffer, not just for the line-number face.  When you turn on the line-numbers display, a single face gets added to the faces used by buffer text -- the font-lock faces each major mode uses.  So how come adding just one face to the dozen of others has such effect?

You are right that there are better ways than linear search to look up a face's attributes by its symbol, and there is a patch in the works to do just that.  But the puzzle here is elsewhere.  Especially since you report significant slowdown due to line numbers in "emacs -Q" as well.

> > An Emacs face that is identified by name needs to be converted to
> the collection of the face's attributes, so that Emacs could merge
> faces and display them.  This is what lface_from_face_name does.  And
> it does that for any face specified in the buffer by its symbol.  So
> how come addition of just one face and a few characters which have
> that face have such a profound effect in your case?
> 
> I'm not sure I track your last question. In my case it's the addition
> of 400-600 faces, none of which are used in the buffer. They just
> exist in the alist that lface_from_face_name_no_resolve scans with
> assq_no_quit.

But the same face alist is searched for faces that _are_ in the buffer: all the font-lock faces.  The line-number face adds just one face to those which Emacs must look up in that alist.

IOW, what puzzles me is not the difference between "emacs -Q" and your customizations, what puzzles me is the difference betwen with and without the line numbers, in the same basic configuration.  It cannot be explained by the length of the frame's face alist alone because in both cases that length is almost identical: you add one face to the list of hundreds.

 This is why TAGGEDP via CONSP is a hotspot in my code,
> because it's called 600 * 700k (or some multiple thereof) times or so.
> assq_no_quit via merge_faces accounts for 1.43s of 6.94s in one of my
> profiles.

How many times is it called with line numbers turned off, and what is the increase in the number of calls due to line numbers in percents?  Does it come anywhere near the slowdown shown in your benchmarks?

Re: macOS metal rendering engine in mac port

[Aaron Jensen]

On Mon, May 24, 2021 at 1:48 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> On May 24, 2021 11:07:42 AM GMT+03:00, Aaron Jensen <aaronjensen@gmail.com> wrote:
> > On Mon, May 24, 2021 at 12:37 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > >
> > > Why does it look suspect to you?  Don't you also see the same code
> > called to process the other faces in the buffer?
> >
> > What looks suspect is that the exact same call is made so many times
> > for the exact same faces and that call gets slower proportional to the
> > number of faces you have because of the linear search. Fewer faces ==
> > less work, and when something is called so many times it may be worth
> > further optimization or caching.
>
> But we do the same for every face in the buffer, not just for the line-number face.  When you turn on the line-numbers display, a single face gets added to the faces used by buffer text -- the font-lock faces each major mode uses.  So how come adding just one face to the dozen of others has such effect?

It's not the extra face. It appears that enabling line numbers calls
merge_faces for those two faces a significant number of times. See
below.

> You are right that there are better ways than linear search to look up a face's attributes by its symbol, and there is a patch in the works to do just that.  But the puzzle here is elsewhere.  Especially since you report significant slowdown due to line numbers in "emacs -Q" as well.

Awesome!

> IOW, what puzzles me is not the difference between "emacs -Q" and your customizations, what puzzles me is the difference betwen with and without the line numbers, in the same basic configuration.  It cannot be explained by the length of the frame's face alist alone because in both cases that length is almost identical: you add one face to the list of hundreds.

Agreed, I was only pointing out the length compounding things because
I made the likely incorrect assumption that the number of times
merge_faces was called when line numbers are turned on was expected.

> How many times is it called with line numbers turned off, and what is the increase in the number of calls due to line numbers in percents?  Does it come anywhere near the slowdown shown in your benchmarks?

With it turned off, merge_faces was called 40 times.
lface_from_face_name_no_resolve was called 143,308 times.

With it on, merge_faces was called 147,882 times and
lface_from_face_name_no_resolve was called 661,238

merge_faces: 369705% more calls
lface_from_face_name_no_resolve: 461% more calls

I'll respond to your second email separately.

Re: macOS metal rendering engine in mac port

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Mon, 24 May 2021 08:32:35 -0700
> Cc: emacs-devel@gnu.org, Alan Third <alan@idiocy.org>, 
> 	YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> 
> > How many times is it called with line numbers turned off, and what is the increase in the number of calls due to line numbers in percents?  Does it come anywhere near the slowdown shown in your benchmarks?
> 
> With it turned off, merge_faces was called 40 times.
> lface_from_face_name_no_resolve was called 143,308 times.
> 
> With it on, merge_faces was called 147,882 times and
> lface_from_face_name_no_resolve was called 661,238
> 
> merge_faces: 369705% more calls
> lface_from_face_name_no_resolve: 461% more calls

Which faces are the those for which merge_faces was called 40 times,
and which faces are those for which it was called 147,882 times.

Also, what did Emacs do when you collected these numbers, and in which
buffer under what major mode?

Re: macOS metal rendering engine in mac port

[Aaron Jensen]

On Mon, May 24, 2021 at 9:29 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> Which faces are the those for which merge_faces was called 40 times,
> and which faces are those for which it was called 147,882 times.

I'll have to get back to you on the 40. The 147k appears to be
entirely line-number and line-number-current-line. If I had to guess,
Emacs is calling merge-faces with line-number and
line-number-current-line for every visible line at least once for
every scroll.

> Also, what did Emacs do when you collected these numbers, and in which
> buffer under what major mode?

emacs -Q src/xdisp.c with scroll-up-benchmark

Re: macOS metal rendering engine in mac port

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Mon, 24 May 2021 09:31:56 -0700
> Cc: emacs-devel@gnu.org, Alan Third <alan@idiocy.org>, 
> 	YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> 
> On Mon, May 24, 2021 at 9:29 AM Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > Which faces are the those for which merge_faces was called 40 times,
> > and which faces are those for which it was called 147,882 times.
> 
> I'll have to get back to you on the 40. The 147k appears to be
> entirely line-number and line-number-current-line. If I had to guess,
> Emacs is calling merge-faces with line-number and
> line-number-current-line for every visible line at least once for
> every scroll.

Of course.  But it also does that for every other face, starting with
font-lock faces.  So something is still amiss here, because 40 is too
small a number.

> > Also, what did Emacs do when you collected these numbers, and in which
> > buffer under what major mode?
> 
> emacs -Q src/xdisp.c with scroll-up-benchmark

Then you should see font-lock-comment-face, font-lock-keyword-face,
font-lock-variable-name-face, etc., and calls to merge_face_ref for
them coming from face_at_buffer_position.

Re: macOS metal rendering engine in mac port

[Aaron Jensen]

On Mon, May 24, 2021 at 9:43 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> Of course.  But it also does that for every other face, starting with
> font-lock faces.  So something is still amiss here, because 40 is too
> small a number.

I'm not seeing this. With line numbers off the only call to
merge_faces is for escape-glyph when I use scroll-up-benchmark. I'm on
Alan's surface-stuff branch if that makes any difference.

> > > Also, what did Emacs do when you collected these numbers, and in which
> > > buffer under what major mode?
> >
> > emacs -Q src/xdisp.c with scroll-up-benchmark
>
> Then you should see font-lock-comment-face, font-lock-keyword-face,
> font-lock-variable-name-face, etc., and calls to merge_face_ref for
> them coming from face_at_buffer_position.

Yeah, I don't see calls to merge_faces for these. Here's the debug code I added:

@@ -6646,10 +6648,16 @@ face_at_string_position (struct window *w,
Lisp_Object string,
    Return new face id.
 */

+long mfc = 0;
+
 int
 merge_faces (struct window *w, Lisp_Object face_name, int face_id,
             int base_face_id)
 {
+
+fprintf(stderr, "x merge_faces: %d %d %ld\n", face_id, base_face_id, mfc++);
+debug_print(face_name);
+
   struct frame *f = WINDOW_XFRAME (w);
   Lisp_Object attrs[LFACE_VECTOR_SIZE];
   struct face *base_face = FACE_FROM_ID_OR_NULL (f, base_face_id);

Re: macOS metal rendering engine in mac port

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Mon, 24 May 2021 10:58:23 -0700
> Cc: emacs-devel@gnu.org, Alan Third <alan@idiocy.org>, 
> 	YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> 
> On Mon, May 24, 2021 at 9:43 AM Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > Of course.  But it also does that for every other face, starting with
> > font-lock faces.  So something is still amiss here, because 40 is too
> > small a number.
> 
> I'm not seeing this. With line numbers off the only call to
> merge_faces is for escape-glyph when I use scroll-up-benchmark. I'm on
> Alan's surface-stuff branch if that makes any difference.
> 
> > > > Also, what did Emacs do when you collected these numbers, and in which
> > > > buffer under what major mode?
> > >
> > > emacs -Q src/xdisp.c with scroll-up-benchmark
> >
> > Then you should see font-lock-comment-face, font-lock-keyword-face,
> > font-lock-variable-name-face, etc., and calls to merge_face_ref for
> > them coming from face_at_buffer_position.
> 
> Yeah, I don't see calls to merge_faces for these. Here's the debug code I added:

I said merge_face_ref, not merge_faces.  See face_at_buffer_position,
which is called whenever the display code finds a new face at some
buffer position.

I don't know what that branch does; I thought we were talking about
the master branch.

Re: macOS metal rendering engine in mac port

[Alan Third]

On Mon, May 24, 2021 at 09:03:12PM +0300, Eli Zaretskii wrote:
> I don't know what that branch does; I thought we were talking about
> the master branch.

It just changes some stuff to do with how we draw the raster buffer to
the screen in nsterm, it doesn't touch any of this stuff, so it should
be the same as the master branch, although maybe a day or two out of
date.
-- 
Alan Third

Re: macOS metal rendering engine in mac port

[Aaron Jensen]

On Mon, May 24, 2021 at 11:03 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> I said merge_face_ref, not merge_faces.  See face_at_buffer_position,
> which is called whenever the display code finds a new face at some
> buffer position.

I see. I was counting merge_faces, but the below numbers are for
merge_face_ref on the master branch.

First run (no line numbers): 131,080
Second run (no line numbers): 130,376
Run with line numbers: 836,569

640% increase

> I don't know what that branch does; I thought we were talking about
> the master branch.

It should be the same for this, it's just changes to ns drawing afaik.
I'll test on master.

Re: macOS metal rendering engine in mac port

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Mon, 24 May 2021 11:18:10 -0700
> Cc: emacs-devel@gnu.org, Alan Third <alan@idiocy.org>, 
> 	YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> 
> On Mon, May 24, 2021 at 11:03 AM Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > I said merge_face_ref, not merge_faces.  See face_at_buffer_position,
> > which is called whenever the display code finds a new face at some
> > buffer position.
> 
> I see. I was counting merge_faces, but the below numbers are for
> merge_face_ref on the master branch.
> 
> First run (no line numbers): 131,080
> Second run (no line numbers): 130,376
> Run with line numbers: 836,569
> 
> 640% increase

That's not the interesting comparison of numbers, because this
function is called recursively.  What is important is that
merge_face_ref is called on behalf of buffer faces roughly the same
number of times as merge_face is called on behalf of line numbers:
about 130,000 to 140,000 for scrolling through xdisp.c.  IOW, the
number of face merges is doubled, it doesn't become 6-fold.

Thus, the slowdown you see in "emacs -Q" is still a mystery for me,
because face merging is far from being the most expensive part of
redisplay.

Maybe there's something NS-specific here, I don't know.  I cannot
explain what you see, and I don't see it on my system.

If you turn on highlight-regexp mode, and use regexps that match about
2 times on each line, do you also see a similar slowdown in the
scrolling benchmark?  For example, highlight two regexps: "^." and
".$".  This should create the same addition of face merges per line as
with line numbers, and so the effect should be similar -- if indeed
the reason is face merges and not something else.  In my testing,
scrolling through xdisp.c with the above 2 regexps highlighted takes
just 2% more time than without them, similar to what I see when I turn
on line numbers.

Re: macOS metal rendering engine in mac port

[Aaron Jensen]

On Mon, May 24, 2021 at 11:55 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> That's not the interesting comparison of numbers, because this
> function is called recursively.  What is important is that
> merge_face_ref is called on behalf of buffer faces roughly the same
> number of times as merge_face is called on behalf of line numbers:
> about 130,000 to 140,000 for scrolling through xdisp.c.  IOW, the
> number of face merges is doubled, it doesn't become 6-fold.

Okay, is there something else you want me to measure?

> Thus, the slowdown you see in "emacs -Q" is still a mystery for me,
> because face merging is far from being the most expensive part of
> redisplay.

lface_from_face_name_no_resolve is called 4.5x more often when line
numbers are enabled and that's enough to make a difference on my
machine.

> Maybe there's something NS-specific here, I don't know.  I cannot
> explain what you see, and I don't see it on my system.

Could you try adding 500 extra (unused) faces and try the comparison
again? The slowdown scales along with the number of faces, so your
linux build may just be better optimized for this particular scenario.

> If you turn on highlight-regexp mode, and use regexps that match about
> 2 times on each line, do you also see a similar slowdown in the
> scrolling benchmark?  For example, highlight two regexps: "^." and
> ".$".  This should create the same addition of face merges per line as
> with line numbers, and so the effect should be similar -- if indeed
> the reason is face merges and not something else.  In my testing,
> scrolling through xdisp.c with the above 2 regexps highlighted takes
> just 2% more time than without them, similar to what I see when I turn
> on line numbers.

emacs -Q
No highlights: 5.47s (slower likely because i'm on master now instead
of Alan's branch)
With highlights: 9.4s

So yes, a similar slowdown for me.

Re: macOS metal rendering engine in mac port

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Mon, 24 May 2021 12:07:44 -0700
> Cc: emacs-devel@gnu.org, Alan Third <alan@idiocy.org>, 
> 	YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> 
> lface_from_face_name_no_resolve is called 4.5x more often when line
> numbers are enabled and that's enough to make a difference on my
> machine.

But it doesn't make any significant difference on mine.  And that's a
mystery.

> Could you try adding 500 extra (unused) faces and try the comparison
> again? The slowdown scales along with the number of faces, so your
> linux build may just be better optimized for this particular scenario.

No, I want to continue using "emacs -Q", because we cannot even
explain the difference in behavior there.  Making the problem we don't
understand more complex will hardly help us understanding it.

> > If you turn on highlight-regexp mode, and use regexps that match about
> > 2 times on each line, do you also see a similar slowdown in the
> > scrolling benchmark?  For example, highlight two regexps: "^." and
> > ".$".  This should create the same addition of face merges per line as
> > with line numbers, and so the effect should be similar -- if indeed
> > the reason is face merges and not something else.  In my testing,
> > scrolling through xdisp.c with the above 2 regexps highlighted takes
> > just 2% more time than without them, similar to what I see when I turn
> > on line numbers.
> 
> emacs -Q
> No highlights: 5.47s (slower likely because i'm on master now instead
> of Alan's branch)
> With highlights: 9.4s
> 
> So yes, a similar slowdown for me.

So the mystery remains...

Thanks.

Re: macOS metal rendering engine in mac port

[Eli Zaretskii]

> Date: Mon, 24 May 2021 22:21:34 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: alan@idiocy.org, mituharu@math.s.chiba-u.ac.jp, emacs-devel@gnu.org
> 
> > emacs -Q
> > No highlights: 5.47s (slower likely because i'm on master now instead
> > of Alan's branch)
> > With highlights: 9.4s
> > 
> > So yes, a similar slowdown for me.
> 
> So the mystery remains...

What about "emacs -Q -nw": do you see a similar slowdown when you turn
on line numbers?

Re: macOS metal rendering engine in mac port

[Aaron Jensen]

On Mon, May 24, 2021 at 12:27 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > Date: Mon, 24 May 2021 22:21:34 +0300
> > From: Eli Zaretskii <eliz@gnu.org>
> > Cc: alan@idiocy.org, mituharu@math.s.chiba-u.ac.jp, emacs-devel@gnu.org
> >
> > > emacs -Q
> > > No highlights: 5.47s (slower likely because i'm on master now instead
> > > of Alan's branch)
> > > With highlights: 9.4s
> > >
> > > So yes, a similar slowdown for me.
> >
> > So the mystery remains...

The mystery to me is how your computer has optimized those extra
calls. What's the result of this for you:

(let ((idx 0))
  (catch 'nth-elt
    (dolist (f face-new-frame-defaults)
      (when (equal 'line-number (car f)) (throw 'nth-elt idx))
      (setq idx (1+ idx)))
    nil))

I get 115.

Also, it just occurred to me that I'm using native-compilation. Are
you? I just tested without native comp and on emacs -Q I got:

7.3s w/o line numbers
8.2s w/ line numbers

> What about "emacs -Q -nw": do you see a similar slowdown when you turn
> on line numbers?

Similar, yes: 1.53s w/o line numbers and 2.12s with line numbers (this
was with native comp).

Re: macOS metal rendering engine in mac port

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Mon, 24 May 2021 13:21:48 -0700
> Cc: Alan Third <alan@idiocy.org>, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>, emacs-devel@gnu.org
> 
> The mystery to me is how your computer has optimized those extra
> calls.

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.

> What's the result of this for you:
> 
> (let ((idx 0))
>   (catch 'nth-elt
>     (dolist (f face-new-frame-defaults)
>       (when (equal 'line-number (car f)) (throw 'nth-elt idx))
>       (setq idx (1+ idx)))
>     nil))
> 
> I get 115.

95 here.

> Also, it just occurred to me that I'm using native-compilation. Are
> you?

No.

> I just tested without native comp and on emacs -Q I got:
> 
> 7.3s w/o line numbers
> 8.2s w/ line numbers

So the effect is still significant, not what I see here.

> > What about "emacs -Q -nw": do you see a similar slowdown when you turn
> > on line numbers?
> 
> Similar, yes: 1.53s w/o line numbers and 2.12s with line numbers (this
> was with native comp).

Sigh.

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?

Re: macOS metal rendering engine in mac port

[Aaron Jensen]

[-- Attachment #1: Type: text/plain, Size: 1846 bytes --]

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?

[-- Attachment #2: CleanShot 2021-05-24 at 23.21.29@2x.png --]
[-- Type: image/png, Size: 1332456 bytes --]

Re: macOS metal rendering engine in mac port

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Mon, 24 May 2021 23:26:37 -0700
> Cc: emacs-devel@gnu.org, Alan Third <alan@idiocy.org>, 
> 	YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> 
> > > 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 17% is about twice what I'd expect, since adding 3 characters to
each line of xdisp.c enlarges its text by only 9.3%.

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

The numbers are so against my intuition that I'm not even sure in
which direction to think...

How did you compile Emacs? which compiler and what compiler and linker
switches?  And what kind of CPU do you have there?  I'm looking for
something that could explain why parts of code that should take like
20% of the total redisplay time are so dominant in your case.

Alan, do you see similar numbers (in percents) to what Aaron reports?
Or is that something peculiar to his system?

Re: macOS metal rendering engine in mac port

[Alan Third]

On Tue, May 25, 2021 at 03:16:17PM +0300, Eli Zaretskii wrote:
> How did you compile Emacs? which compiler and what compiler and linker
> switches?  And what kind of CPU do you have there?  I'm looking for
> something that could explain why parts of code that should take like
> 20% of the total redisplay time are so dominant in your case.
> 
> Alan, do you see similar numbers (in percents) to what Aaron reports?
> Or is that something peculiar to his system?

I did some trials last night using the highlight-regexp technique but
didn't note the times. They're in the same ball park as Aaron's.

Interestingly I also see them on a Debian system, so I just checked
and it looks like Emacs is being built with clang there. The NS port
can only be built on macOS with clang, so Aaron will be using it.

I'll have another look this evening to see if I can rule out clang
being responsible.
-- 
Alan Third

Re: macOS metal rendering engine in mac port

[Alan Third]

On Tue, May 25, 2021 at 03:16:17PM +0300, Eli Zaretskii wrote:
> Alan, do you see similar numbers (in percents) to what Aaron reports?
> Or is that something peculiar to his system?

In fact, I just ran the highlight-regexp test on a GTK build that's
definitely built with GCC and -Q I got:

without:

3.2s 3.0s 3.3s

with:

3.7s 3.7s 4s
-- 
Alan Third

Re: macOS metal rendering engine in mac port

[Eli Zaretskii]

> Date: Tue, 25 May 2021 13:56:43 +0100
> From: Alan Third <alan@idiocy.org>
> Cc: Aaron Jensen <aaronjensen@gmail.com>, emacs-devel@gnu.org,
> 	mituharu@math.s.chiba-u.ac.jp
> 
> On Tue, May 25, 2021 at 03:16:17PM +0300, Eli Zaretskii wrote:
> > Alan, do you see similar numbers (in percents) to what Aaron reports?
> > Or is that something peculiar to his system?
> 
> In fact, I just ran the highlight-regexp test on a GTK build that's
> definitely built with GCC and -Q I got:
> 
> without:
> 
> 3.2s 3.0s 3.3s
> 
> with:
> 
> 3.7s 3.7s 4s

And what's the effect of display-line-numbers-mode?

Re: macOS metal rendering engine in mac port

[Alan Third]

On Tue, May 25, 2021 at 04:00:11PM +0300, Eli Zaretskii wrote:
> > Date: Tue, 25 May 2021 13:56:43 +0100
> > From: Alan Third <alan@idiocy.org>
> > Cc: Aaron Jensen <aaronjensen@gmail.com>, emacs-devel@gnu.org,
> > 	mituharu@math.s.chiba-u.ac.jp
> > 
> > On Tue, May 25, 2021 at 03:16:17PM +0300, Eli Zaretskii wrote:
> > > Alan, do you see similar numbers (in percents) to what Aaron reports?
> > > Or is that something peculiar to his system?
> > 
> > In fact, I just ran the highlight-regexp test on a GTK build that's
> > definitely built with GCC and -Q I got:
> > 
> > without:
> > 
> > 3.2s 3.0s 3.3s
> > 
> > with:
> > 
> > 3.7s 3.7s 4s
> 
> And what's the effect of display-line-numbers-mode?

without:

4.3 4.3 4.5

with:

5.2 5.4 5.4

I don't know why this set of runs is a second slower, but it's still
consistent. I made a few extra runs after with it off and the numbers
went back down to just over 4 seconds.

-- 
Alan Third

Re: macOS metal rendering engine in mac port

[Eli Zaretskii]

> Date: Tue, 25 May 2021 14:07:07 +0100
> From: Alan Third <alan@idiocy.org>
> Cc: aaronjensen@gmail.com, emacs-devel@gnu.org
> 
> > And what's the effect of display-line-numbers-mode?
> 
> without:
> 
> 4.3 4.3 4.5
> 
> with:
> 
> 5.2 5.4 5.4

That's about 25%, which AFAIU is much smaller effect than what Aaron
sees?

Re: macOS metal rendering engine in mac port

[Alan Third]

On Tue, May 25, 2021 at 04:18:06PM +0300, Eli Zaretskii wrote:
> > Date: Tue, 25 May 2021 14:07:07 +0100
> > From: Alan Third <alan@idiocy.org>
> > Cc: aaronjensen@gmail.com, emacs-devel@gnu.org
> > 
> > > And what's the effect of display-line-numbers-mode?
> > 
> > without:
> > 
> > 4.3 4.3 4.5
> > 
> > with:
> > 
> > 5.2 5.4 5.4
> 
> That's about 25%, which AFAIU is much smaller effect than what Aaron
> sees?

I've not been following this bit of the thread in detail, but I
thought it was in line with what he sees when he uses -Q, and that's
what I'm using. I imagine I'm misunderstanding.

FWIW, on the Mac I see a slightly smaller performance penalty with
display-line-numbers-mode, around 18%.
-- 
Alan Third

Re: macOS metal rendering engine in mac port

[Eli Zaretskii]

> Date: Tue, 25 May 2021 14:34:37 +0100
> From: Alan Third <alan@idiocy.org>
> Cc: aaronjensen@gmail.com, emacs-devel@gnu.org
> 
> FWIW, on the Mac I see a slightly smaller performance penalty with
> display-line-numbers-mode, around 18%.

Is that an optimized build or unoptimized?  In my tests with optimized
builds, line numbers add about 10% to 12% to the scroll benchmark.
Unoptimized code shows almost no effect: around 2%.

Re: macOS metal rendering engine in mac port

[Alan Third]

On Tue, May 25, 2021 at 04:47:41PM +0300, Eli Zaretskii wrote:
> > Date: Tue, 25 May 2021 14:34:37 +0100
> > From: Alan Third <alan@idiocy.org>
> > Cc: aaronjensen@gmail.com, emacs-devel@gnu.org
> > 
> > FWIW, on the Mac I see a slightly smaller performance penalty with
> > display-line-numbers-mode, around 18%.
> 
> Is that an optimized build or unoptimized?  In my tests with optimized
> builds, line numbers add about 10% to 12% to the scroll benchmark.
> Unoptimized code shows almost no effect: around 2%.

In both cases the default, so -O2.
-- 
Alan Third

Re: macOS metal rendering engine in mac port

[Eli Zaretskii]

> Date: Tue, 25 May 2021 13:56:43 +0100
> From: Alan Third <alan@idiocy.org>
> Cc: Aaron Jensen <aaronjensen@gmail.com>, emacs-devel@gnu.org,
> 	mituharu@math.s.chiba-u.ac.jp
> 
> In fact, I just ran the highlight-regexp test on a GTK build that's
> definitely built with GCC and -Q I got:
> 
> without:
> 
> 3.2s 3.0s 3.3s
> 
> with:
> 
> 3.7s 3.7s 4s

So I'm sure I understand: it takes you just 3 seconds to scroll
through all of xdisp.c, top to bottom, with the command below?

(defun scroll-up-benchmark ()
  (interactive)
  (let ((oldgc gcs-done)
        (oldtime (float-time)))
    (condition-case nil (while t (scroll-up) (redisplay))
      (error (message "GCs: %d Elapsed time: %f seconds"
                      (- gcs-done oldgc) (- (float-time) oldtime))))))

Re: macOS metal rendering engine in mac port

[Alan Third]

On Thu, May 27, 2021 at 07:55:41PM +0300, Eli Zaretskii wrote:
> > Date: Tue, 25 May 2021 13:56:43 +0100
> > From: Alan Third <alan@idiocy.org>
> > Cc: Aaron Jensen <aaronjensen@gmail.com>, emacs-devel@gnu.org,
> > 	mituharu@math.s.chiba-u.ac.jp
> > 
> > In fact, I just ran the highlight-regexp test on a GTK build that's
> > definitely built with GCC and -Q I got:
> > 
> > without:
> > 
> > 3.2s 3.0s 3.3s
> > 
> > with:
> > 
> > 3.7s 3.7s 4s
> 
> So I'm sure I understand: it takes you just 3 seconds to scroll
> through all of xdisp.c, top to bottom, with the command below?
> 
> (defun scroll-up-benchmark ()
>   (interactive)
>   (let ((oldgc gcs-done)
>         (oldtime (float-time)))
>     (condition-case nil (while t (scroll-up) (redisplay))
>       (error (message "GCs: %d Elapsed time: %f seconds"
>                       (- gcs-done oldgc) (- (float-time) oldtime))))))

Yes, although the initial run through, where the file is font-locked,
is more like 22 seconds. I didn't count that, am I measuring this wrongly?
-- 
Alan Third

Re: macOS metal rendering engine in mac port

[Eli Zaretskii]

> Date: Thu, 27 May 2021 18:40:54 +0100
> From: Alan Third <alan@idiocy.org>
> Cc: aaronjensen@gmail.com, emacs-devel@gnu.org,
> 	mituharu@math.s.chiba-u.ac.jp
> 
> > > 3.7s 3.7s 4s
> > 
> > So I'm sure I understand: it takes you just 3 seconds to scroll
> > through all of xdisp.c, top to bottom, with the command below?
> > 
> > (defun scroll-up-benchmark ()
> >   (interactive)
> >   (let ((oldgc gcs-done)
> >         (oldtime (float-time)))
> >     (condition-case nil (while t (scroll-up) (redisplay))
> >       (error (message "GCs: %d Elapsed time: %f seconds"
> >                       (- gcs-done oldgc) (- (float-time) oldtime))))))
> 
> Yes, although the initial run through, where the file is font-locked,
> is more like 22 seconds. I didn't count that, am I measuring this wrongly?

Yes, I meant to measure just the first scroll, and restart Emacs each
time before another measurement.

So maybe we were comparing apples and oranges all the time.

Re: macOS metal rendering engine in mac port

[Alan Third]

On Thu, May 27, 2021 at 08:47:57PM +0300, Eli Zaretskii wrote:
> > Date: Thu, 27 May 2021 18:40:54 +0100
> > From: Alan Third <alan@idiocy.org>
> > Cc: aaronjensen@gmail.com, emacs-devel@gnu.org,
> > 	mituharu@math.s.chiba-u.ac.jp
> > 
> > > > 3.7s 3.7s 4s
> > > 
> > > So I'm sure I understand: it takes you just 3 seconds to scroll
> > > through all of xdisp.c, top to bottom, with the command below?
> > > 
> > > (defun scroll-up-benchmark ()
> > >   (interactive)
> > >   (let ((oldgc gcs-done)
> > >         (oldtime (float-time)))
> > >     (condition-case nil (while t (scroll-up) (redisplay))
> > >       (error (message "GCs: %d Elapsed time: %f seconds"
> > >                       (- gcs-done oldgc) (- (float-time) oldtime))))))
> > 
> > Yes, although the initial run through, where the file is font-locked,
> > is more like 22 seconds. I didn't count that, am I measuring this wrongly?
> 
> Yes, I meant to measure just the first scroll, and restart Emacs each
> time before another measurement.
> 
> So maybe we were comparing apples and oranges all the time.

Possibly. I started off in this thread trying to measure the final
to the glass drawing time, so excluding the first run with the font
locking made sense, but I guess not so much for the question of what
happens with line numbers.

I suspect from Aaron's number's he's been doing the same as me. Unless
the M1 Macs really are that fast...
-- 
Alan Third

Re: macOS metal rendering engine in mac port

[Aaron Jensen]

On Thu, May 27, 2021 at 10:51 AM Alan Third <alan@idiocy.org> wrote:
>
> I suspect from Aaron's number's he's been doing the same as me. Unless
> the M1 Macs really are that fast...

I believe I've mentioned I'm discarding the first scroll each time,
but yes, I am discarding the first scroll. And Intel here still... M1
maybe after the next batch are released.

Eli, if you test the 2nd scroll do you see a bigger difference?

Re: macOS metal rendering engine in mac port

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Thu, 27 May 2021 10:53:07 -0700
> 
> Eli, if you test the 2nd scroll do you see a bigger difference?

About 17% to 20% difference.  Still quite mild, I'd say.

Re: macOS metal rendering engine in mac port

[Aaron Jensen]

On Thu, May 27, 2021 at 11:59 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Aaron Jensen <aaronjensen@gmail.com>
> > Date: Thu, 27 May 2021 10:53:07 -0700
> >
> > Eli, if you test the 2nd scroll do you see a bigger difference?
>
> About 17% to 20% difference.  Still quite mild, I'd say.

Can you share your times with line numbers and without? My % varies
wildly based on rendering time. That is, when I try different
renderers the delta in seconds stays the same, but the % increase goes
up as the rendering gets smaller.

Re: macOS metal rendering engine in mac port

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Thu, 27 May 2021 12:02:33 -0700
> Cc: Alan Third <alan@idiocy.org>, emacs-devel@gnu.org, 
> 	YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> 
> > About 17% to 20% difference.  Still quite mild, I'd say.
> 
> Can you share your times with line numbers and without? My % varies
> wildly based on rendering time. That is, when I try different
> renderers the delta in seconds stays the same, but the % increase goes
> up as the rendering gets smaller.

If the delta in seconds is the same, it probably means the variations
in total time are independent of the issue we are discussing.  The
face merging is entirely in platform-independent code, which knows
nothing about the actual writing to the glass.

As for times: do you want an optimized or an unoptimized build?  Does
it matter if it's Emacs 27 or 28?  And does it matter that my builds
are 32-bit builds --with-wide-int, which slows down Emacs by about
30%?  When I know which numbers you want to see, I will produce them.
(Of course, it is easier for me to produce numbers from a build I
already have, otherwise I'd need to build it first.)

Re: macOS metal rendering engine in mac port

[Aaron Jensen]

On Thu, May 27, 2021 at 12:22 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> If the delta in seconds is the same, it probably means the variations
> in total time are independent of the issue we are discussing.  The
> face merging is entirely in platform-independent code, which knows
> nothing about the actual writing to the glass.

Yeah, I think that's my point. %'s probably don't matter, it's the
seconds that matter. I only saw %s from you, which is why I was
asking.

> As for times: do you want an optimized or an unoptimized build?  Does
> it matter if it's Emacs 27 or 28?  And does it matter that my builds
> are 32-bit builds --with-wide-int, which slows down Emacs by about
> 30%?  When I know which numbers you want to see, I will produce them.
> (Of course, it is easier for me to produce numbers from a build I
> already have, otherwise I'd need to build it first.)

All my recent times are on unoptimized and on Emacs 28. I'm building
the default architecture on macOS, which I imagine is 64 bit.

Re: macOS metal rendering engine in mac port

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Thu, 27 May 2021 12:37:33 -0700
> Cc: Alan Third <alan@idiocy.org>, emacs-devel@gnu.org, 
> 	YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> 
> > As for times: do you want an optimized or an unoptimized build?  Does
> > it matter if it's Emacs 27 or 28?  And does it matter that my builds
> > are 32-bit builds --with-wide-int, which slows down Emacs by about
> > 30%?  When I know which numbers you want to see, I will produce them.
> > (Of course, it is easier for me to produce numbers from a build I
> > already have, otherwise I'd need to build it first.)
> 
> All my recent times are on unoptimized and on Emacs 28. I'm building
> the default architecture on macOS, which I imagine is 64 bit.

In an unoptimized 32-bit build --with-wide-int:

  . Without line numbers: 15.9 sec.
  . With line numbers: 19.7 sec.

The times are quite consistent, with jitter of less than 0.1 sec.

Note that I don't consider this (i.e. scrolling through a buffer that
was already completely font-locked in advance) an important use case
for the redisplay purposes, because with today's JIT font-lock this
almost never happens.

Re: macOS metal rendering engine in mac port

[Aaron Jensen]

On Fri, May 28, 2021 at 10:58 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Aaron Jensen <aaronjensen@gmail.com>
> > Date: Thu, 27 May 2021 12:37:33 -0700
> > Cc: Alan Third <alan@idiocy.org>, emacs-devel@gnu.org,
> >       YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> >
> > > As for times: do you want an optimized or an unoptimized build?  Does
> > > it matter if it's Emacs 27 or 28?  And does it matter that my builds
> > > are 32-bit builds --with-wide-int, which slows down Emacs by about
> > > 30%?  When I know which numbers you want to see, I will produce them.
> > > (Of course, it is easier for me to produce numbers from a build I
> > > already have, otherwise I'd need to build it first.)
> >
> > All my recent times are on unoptimized and on Emacs 28. I'm building
> > the default architecture on macOS, which I imagine is 64 bit.

I must have written this in a rush. I build optimized, not unoptimized.

> In an unoptimized 32-bit build --with-wide-int:
>
>   . Without line numbers: 15.9 sec.
>   . With line numbers: 19.7 sec.
>
> The times are quite consistent, with jitter of less than 0.1 sec.
>
> Note that I don't consider this (i.e. scrolling through a buffer that
> was already completely font-locked in advance) an important use case
> for the redisplay purposes, because with today's JIT font-lock this
> almost never happens.

Is that because the font-locking gets garbage collected over time? And
I agree, I don't think holding the scroll button down to get to the
bottom of the file is an important use case. It's just been used as a
proxy for rendering performance/framerate testing.

Re: macOS metal rendering engine in mac port

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Fri, 28 May 2021 11:21:18 -0700
> Cc: Alan Third <alan@idiocy.org>, emacs-devel@gnu.org, 
> 	YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> 
> > > All my recent times are on unoptimized and on Emacs 28. I'm building
> > > the default architecture on macOS, which I imagine is 64 bit.
> 
> I must have written this in a rush. I build optimized, not unoptimized.

I can show times from an optimized build of Emacs 27.2.  I don't have
optimized builds of Emacs 28 yet.

> > Note that I don't consider this (i.e. scrolling through a buffer that
> > was already completely font-locked in advance) an important use case
> > for the redisplay purposes, because with today's JIT font-lock this
> > almost never happens.
> 
> Is that because the font-locking gets garbage collected over time?

No, because JIT font-lock only fontifies what you display, and files
of significant size are almost never displayed in their entirety.  You
only display what you work on.

> And I agree, I don't think holding the scroll button down to get to
> the bottom of the file is an important use case. It's just been used
> as a proxy for rendering performance/framerate testing.

That's not my point: scrolling through an unfontified buffer is
definitely an important use case.

Re: macOS metal rendering engine in mac port

[Aaron Jensen]

On Tue, May 25, 2021 at 5:16 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Aaron Jensen <aaronjensen@gmail.com>
> > Date: Mon, 24 May 2021 23:26:37 -0700
> > Cc: emacs-devel@gnu.org, Alan Third <alan@idiocy.org>,
> >       YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> >
> > > > 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 17% is about twice what I'd expect, since adding 3 characters to
> each line of xdisp.c enlarges its text by only 9.3%.

Pure guess here, but it's also making a lot of empty lines non-empty
(14% more). Perhaps that has an added cost somehow?

> > 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?
>
> The numbers are so against my intuition that I'm not even sure in
> which direction to think...
>
> How did you compile Emacs? which compiler and what compiler and linker
> switches?  And what kind of CPU do you have there?  I'm looking for
> something that could explain why parts of code that should take like
> 20% of the total redisplay time are so dominant in your case.

clang, with -O2. Specifically these configure flags:

CFLAGS="-g3 -O2" \
--disable-silent-rules \
--with-xml2 \
--with-gnutls \
--without-dbus \
--with-imagemagick \
--with-modules \
--with-rsvg \
--with-ns \
--disable-ns-self-contained


This CPU: Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz

>
> Alan, do you see similar numbers (in percents) to what Aaron reports?
> Or is that something peculiar to his system?

What I get depends on frame size and whether or not I'm using
nativecomp or Alan's branch or master. I just a test with a smaller
frame size (on Alan's branch this time, just happens to be what I have
built) and saw 5.58 vs 6.8s: 22%. But then I ran the bench again w/
line numbers and couldn't get it below 7.2s, so there's quite a bit of
variability in the test runs.

Alan, I haven't forgotten about your question about latency and that
additional patch. I'm using that patch now and will work with it
through the day.

Re: macOS metal rendering engine in mac port

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Tue, 25 May 2021 08:35:42 -0700
> Cc: emacs-devel@gnu.org, Alan Third <alan@idiocy.org>, 
> 	YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> 
> > The 17% is about twice what I'd expect, since adding 3 characters to
> > each line of xdisp.c enlarges its text by only 9.3%.
> 
> Pure guess here, but it's also making a lot of empty lines non-empty
> (14% more). Perhaps that has an added cost somehow?

Not AFAIU, but I had so many surprises in this investigation that I no
longer believe in my intuition.  So who knows, maybe you are right.

> > How did you compile Emacs? which compiler and what compiler and linker
> > switches?  And what kind of CPU do you have there?  I'm looking for
> > something that could explain why parts of code that should take like
> > 20% of the total redisplay time are so dominant in your case.
> 
> clang, with -O2. Specifically these configure flags:
> 
> CFLAGS="-g3 -O2" \
> --disable-silent-rules \
> --with-xml2 \
> --with-gnutls \
> --without-dbus \
> --with-imagemagick \
> --with-modules \
> --with-rsvg \
> --with-ns \
> --disable-ns-self-contained
> 
> 
> This CPU: Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz

So you have 16 execution units, but a relatively slow clock.  Hmm...

> > Alan, do you see similar numbers (in percents) to what Aaron reports?
> > Or is that something peculiar to his system?
> 
> What I get depends on frame size and whether or not I'm using
> nativecomp or Alan's branch or master. I just a test with a smaller
> frame size (on Alan's branch this time, just happens to be what I have
> built) and saw 5.58 vs 6.8s: 22%. But then I ran the bench again w/
> line numbers and couldn't get it below 7.2s, so there's quite a bit of
> variability in the test runs.

FWIW, in my case, the default frame size (~37 lines) and a maximized
frame produce the same timings here.

Re: macOS metal rendering engine in mac port

[Aaron Jensen]

On Tue, May 25, 2021 at 10:34 AM Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > This CPU: Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz
>
> So you have 16 execution units, but a relatively slow clock.  Hmm...

It's a laptop, so the low clock is power saving. It has turbo boost to
5GHz, though thermally I don't think I can actually hit that for very
long, if at all. But at least 4.3GHz or so.

Re: macOS metal rendering engine in mac port

[Alan Third]

On Mon, May 24, 2021 at 09:42:45PM -0700, Aaron Jensen wrote:
> 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.

The surface contents are just an array of bytes and the whole lot are
copied every time, so no, what's displayed will have no effect on the
copy.
-- 
Alan Third

Re: macOS metal rendering engine in mac port

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Sun, 23 May 2021 20:56:08 -0700
> Cc: Alan Third <alan@idiocy.org>, emacs-devel@gnu.org, 
> 	YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> 
> Here are some interesting profile pictures. On the left is emacs -Q w/
> display-line-numbers-mode. On the right is a partial version of my
> config with some of the things I mentioned before removed. Most of the
> difference between the two comes in the amount of time spent in
> merge_faces. My config ends up spending roughly 7.5x more time in
> merge_faces (1500ms vs 200ms). What causes that to get slower?

Some observations about these profiles:

First, given the non-repeatability of the benchmarks whose data you
exchanged with Alan, I'm not sure we should trust these profiles.

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.

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.

Thanks.

Re: macOS metal rendering engine in mac port

[Aaron Jensen]

[-- Attachment #1: Type: text/plain, Size: 2223 bytes --]

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.

[-- Attachment #2: CleanShot 2021-05-24 at 08.59.53@2x.png --]
[-- Type: image/png, Size: 1356344 bytes --]

Re: macOS metal rendering engine in mac port

[Alan Third]

On Sun, May 23, 2021 at 10:06:35AM -0700, Aaron Jensen wrote:
> On Sun, May 23, 2021 at 9:13 AM Aaron Jensen <aaronjensen@gmail.com> wrote:
> >
> > I've been using it and haven't seen any flickers. I'll continue using
> > it and report back. I probably would have seen one by now.
> 
> So one important note, I'm selling my 5k2k giant monitor so it's boxed
> up (if anyone is interested, email me :) ). I'm on a 24" 4k monitor
> now running at 1920x1080 scaled, whereas before I was at 3008x1269.
> 
> So, this morning when I run the scroll-up-benchmark it does what the
> macport did. That is, it looks like it hangs for a second, shows maybe
> 1 or two scrolls and then jumps to the bottom.

Told you I'd back-port that fix. ;)

I've seen similar, but only when I start the benchmark then click on
another window. My thinking was that macOS was seeing I'm no longer
using it and put it into some low-performance mode. But clicking back
in the window doesn't fix it. I've no idea what's going on and I've
only seen it happen when using the benchmark so I've not investigated.

> I get roughly 2.3s w/ line numbers and 1.16 without.
> 
> On the new surface-stuff branch, I get 4.7s w/ line numbers and 2.98s w/o.

I've made surface-stuff as much like the (non-metal) mac port as I
possibly can. I'm not seeing any difference. I've put an NSLog at the
start of keyDown and another at the end of updateLayer, and the time
difference is pretty consistently about 3ms, so I don't think the NS
port's IO is slow. That leaves the time between the key being hit and
the NS port registering it, which I don't think we can do anything
about, or the time between us passing the IOSurface to the system and
it actually displaying, which should be identical to the Mac port,
unless it's using some sneaky setting I've yet to discover.

If it's still laggy, I've got absolutely no idea.

-- 
Alan Third

Re: macOS metal rendering engine in mac port

[Alan Third]

On Sun, May 23, 2021 at 10:20:49PM +0100, Alan Third wrote:
> If it's still laggy, I've got absolutely no idea.

OK, one more idea:

Search for RGBA in nsterm.m and change it to BGRA.

I expect this to make everything much slower, it does here, but who knows.
-- 
Alan Third

Re: macOS metal rendering engine in mac port

[Alan Third]

On Sun, May 23, 2021 at 11:04:51PM +0100, Alan Third wrote:
> On Sun, May 23, 2021 at 10:20:49PM +0100, Alan Third wrote:
> > If it's still laggy, I've got absolutely no idea.
> 
> OK, one more idea:
> 
> Search for RGBA in nsterm.m and change it to BGRA.
> 
> I expect this to make everything much slower, it does here, but who knows.

Actually, nope, forget that.
-- 
Alan Third

Re: macOS metal rendering engine in mac port

[Alan Third]

On Sun, May 23, 2021 at 09:13:51AM -0700, Aaron Jensen wrote:
> On Sun, May 23, 2021 at 4:47 AM Alan Third <alan@idiocy.org> wrote:
> > >
> > > Mine are fairly consistent. I imagine hitting thermal would hurt
> > > though and Intel macs love to do that.
> >
> > Yeah, I wonder if that's what's happening. I have to say that I don't
> > think this Mac has ever been what I'd consider fast. My ancient first
> > gen i7 absolutely wipes the floor with it in compilation speed
> > despite being at least 7 years older. I guess Moores law really did
> > run out of steam. ;)
> 
> I'm curious what chip you have? I have a 2.4 GHz I9-9980HK and it's
> not slow to compile, but the linux machine I was using for a while
> demolished it. Of course, that was a 16 core 3950X, so...

It's a 2.7GHz i5 with two real cores and Iris graphics.

> Interesting. And generally speaking, are there licensing issues
> preventing a merge/collaboration w/ the mac port?

We already use the Mac port font backend (although I suspect they may
have diverged a little over time). Other than that I don't know how
much "collaboration" would be practical, and anything else would be simply
throwing the NS port out altogether and replacing it with the Mac
port, although then it would be subject to the same rules as the NS
port which may or may not be to Yamamoto Mitsuharu's taste.

I don't really care one way or the other, I'm already using my new
ThinkPad as my daily driver and it would be quite nice to see the back
of the people on Reddit telling me I'm actively harming the Free
Software movement by maintaining the NS port instead of letting it die
so everyone is forced to use the Mac port.

> > It's a lot of work. I'd have to be sure that the patch actually stops
> > the flashing and blanking before I tried that. I'm not hopeful, tbh.
> 
> I've been using it and haven't seen any flickers. I'll continue using
> it and report back. I probably would have seen one by now.

My configuration seems to not even work with Emacs 27 any more, so I
can't properly use it myself.

-- 
Alan Third

Re: macOS metal rendering engine in mac port

[Aaron Jensen]

On Sun, May 23, 2021 at 2:08 PM Alan Third <alan@idiocy.org> wrote:
>
> > Interesting. And generally speaking, are there licensing issues
> > preventing a merge/collaboration w/ the mac port?
>
> We already use the Mac port font backend (although I suspect they may
> have diverged a little over time). Other than that I don't know how
> much "collaboration" would be practical, and anything else would be simply
> throwing the NS port out altogether and replacing it with the Mac
> port, although then it would be subject to the same rules as the NS
> port which may or may not be to Yamamoto Mitsuharu's taste.

I see, is that the rules about how nothing can be done in a Non-free
OS port that a free OS cannot do?

> I don't really care one way or the other, I'm already using my new
> ThinkPad as my daily driver and it would be quite nice to see the back
> of the people on Reddit telling me I'm actively harming the Free
> Software movement by maintaining the NS port instead of letting it die
> so everyone is forced to use the Mac port.

Wow, people are jerks. I'm sorry you have to put up with that. For
what it's worth, I appreciate your work. I've never found the mac port
to work for me (though they just fixed the long-standing gui/tty
server issue which was a big one for me). This is the first time I've
used the mac port and thought ok, this may work, but then because it's
not on 28 yet, I miss native comp. I just can't have it all.

> > > It's a lot of work. I'd have to be sure that the patch actually stops
> > > the flashing and blanking before I tried that. I'm not hopeful, tbh.
> >
> > I've been using it and haven't seen any flickers. I'll continue using
> > it and report back. I probably would have seen one by now.
>
> My configuration seems to not even work with Emacs 27 any more, so I
> can't properly use it myself.

Copy that. I'll keep using it.

> On Sun, May 23, 2021 at 10:06:35AM -0700, Aaron Jensen wrote:
>
> Told you I'd back-port that fix. ;)

Hah, I wasn't going to say anything...

> I've seen similar, but only when I start the benchmark then click on
> another window. My thinking was that macOS was seeing I'm no longer
> using it and put it into some low-performance mode. But clicking back
> in the window doesn't fix it. I've no idea what's going on and I've
> only seen it happen when using the benchmark so I've not investigated.

Yeah, I wouldn't worry about it. I restarted and it was normal. 2.98s
for line numbers, 1.57s w/o. So still quite a bit faster than 28
surface stuff.

I also just tested macport with a stopwatch and it's very close to 28.
4.5s w/ line numbers.

> I've made surface-stuff as much like the (non-metal) mac port as I
> possibly can. I'm not seeing any difference. I've put an NSLog at the
> start of keyDown and another at the end of updateLayer, and the time
> difference is pretty consistently about 3ms, so I don't think the NS
> port's IO is slow. That leaves the time between the key being hit and
> the NS port registering it, which I don't think we can do anything
> about, or the time between us passing the IOSurface to the system and
> it actually displaying, which should be identical to the Mac port,
> unless it's using some sneaky setting I've yet to discover.
>
> If it's still laggy, I've got absolutely no idea.

Interesting. Well I know that my config is adding some latency. Likely
company, flyspell, flycheck, etc. I'll keep digging on my end too.

Thanks,

Aaron

Re: macOS metal rendering engine in mac port

[Alan Third]

On Sun, May 23, 2021 at 03:37:11PM -0700, Aaron Jensen wrote:
> On Sun, May 23, 2021 at 2:08 PM Alan Third <alan@idiocy.org> wrote:
> >
> > > Interesting. And generally speaking, are there licensing issues
> > > preventing a merge/collaboration w/ the mac port?
> >
> > We already use the Mac port font backend (although I suspect they may
> > have diverged a little over time). Other than that I don't know how
> > much "collaboration" would be practical, and anything else would be simply
> > throwing the NS port out altogether and replacing it with the Mac
> > port, although then it would be subject to the same rules as the NS
> > port which may or may not be to Yamamoto Mitsuharu's taste.
> 
> I see, is that the rules about how nothing can be done in a Non-free
> OS port that a free OS cannot do?

I think so. A lot of what people like (smooth scrolling, etc.) would
have to be removed.

> > I've made surface-stuff as much like the (non-metal) mac port as I
> > possibly can. I'm not seeing any difference. I've put an NSLog at the
> > start of keyDown and another at the end of updateLayer, and the time
> > difference is pretty consistently about 3ms, so I don't think the NS
> > port's IO is slow. That leaves the time between the key being hit and
> > the NS port registering it, which I don't think we can do anything
> > about, or the time between us passing the IOSurface to the system and
> > it actually displaying, which should be identical to the Mac port,
> > unless it's using some sneaky setting I've yet to discover.
> >
> > If it's still laggy, I've got absolutely no idea.
> 
> Interesting. Well I know that my config is adding some latency. Likely
> company, flyspell, flycheck, etc. I'll keep digging on my end too.

One more thing to try...

modified   src/nsterm.m
@@ -8376,7 +8376,13 @@ - (void)unfocusDrawingBuffer
   NSTRACE ("[EmacsView unfocusDrawingBuffer]");
 
   [NSGraphicsContext setCurrentContext:nil];
-  [self setNeedsDisplay:YES];
+  [surface releaseContext];
+  [[self layer] setContents:(id)[surface getSurface]];
+  [surface performSelectorOnMainThread:@selector (getContext)
+                            withObject:nil
+                         waitUntilDone:NO];
+
+  //[self setNeedsDisplay:YES];
 }
 
 
@@ -8513,11 +8519,11 @@ - (void)updateLayer
      There's a private method, -[CALayer setContentsChanged], that we
      could use to force it, but we shouldn't often get the same
      surface twice in a row.  */
-  [surface releaseContext];
-  [[self layer] setContents:(id)[surface getSurface]];
-  [surface performSelectorOnMainThread:@selector (getContext)
-                            withObject:nil
-                         waitUntilDone:NO];
+  // [surface releaseContext];
+  // [[self layer] setContents:(id)[surface getSurface]];
+  // [surface performSelectorOnMainThread:@selector (getContext)
+  //                           withObject:nil
+  //                        waitUntilDone:NO];
 }
 #endif


All this does is reduce the time between us deciding we're done with
drawing and sending it off to VRAM (although it might not, I'm not
entirely sure when updateLayer gets called).

I expect this to reduce frame rate, but perhaps it will improve input
lag a little.

What's the overall situation just now with the various branches? I
don't actually care too much about frame rate, I think it's probably
fast enough in all cases, but I'm interested in input lag. Has
anything I've done improved it?
-- 
Alan Third

Re: macOS metal rendering engine in mac port

[Aaron Jensen]

On Mon, May 24, 2021 at 2:01 AM Alan Third <alan@idiocy.org> wrote:
>
> I think so. A lot of what people like (smooth scrolling, etc.) would
> have to be removed.

Weird, this has never worked for me, but maybe I've had it misconfigured

> One more thing to try...
>
> modified   src/nsterm.m
> @@ -8376,7 +8376,13 @@ - (void)unfocusDrawingBuffer
>    NSTRACE ("[EmacsView unfocusDrawingBuffer]");
>
>    [NSGraphicsContext setCurrentContext:nil];
> -  [self setNeedsDisplay:YES];
> +  [surface releaseContext];
> +  [[self layer] setContents:(id)[surface getSurface]];
> +  [surface performSelectorOnMainThread:@selector (getContext)
> +                            withObject:nil
> +                         waitUntilDone:NO];
> +
> +  //[self setNeedsDisplay:YES];
>  }
>
>
> @@ -8513,11 +8519,11 @@ - (void)updateLayer
>       There's a private method, -[CALayer setContentsChanged], that we
>       could use to force it, but we shouldn't often get the same
>       surface twice in a row.  */
> -  [surface releaseContext];
> -  [[self layer] setContents:(id)[surface getSurface]];
> -  [surface performSelectorOnMainThread:@selector (getContext)
> -                            withObject:nil
> -                         waitUntilDone:NO];
> +  // [surface releaseContext];
> +  // [[self layer] setContents:(id)[surface getSurface]];
> +  // [surface performSelectorOnMainThread:@selector (getContext)
> +  //                           withObject:nil
> +  //                        waitUntilDone:NO];
>  }
>  #endif
>
>
> All this does is reduce the time between us deciding we're done with
> drawing and sending it off to VRAM (although it might not, I'm not
> entirely sure when updateLayer gets called).
>
> I expect this to reduce frame rate, but perhaps it will improve input
> lag a little.

I don't know if it's something funky with my machine or not but I've
noticed some stutters with this patch. As in, it appears to miss
paints. I'll type a character and won't see it until I type something
else. Is it possible that this patch could cause that?

Thanks,

Aaron

Re: macOS metal rendering engine in mac port

[Aaron Jensen]

On Tue, May 25, 2021 at 9:31 AM Aaron Jensen <aaronjensen@gmail.com> wrote:
>
> On Mon, May 24, 2021 at 2:01 AM Alan Third <alan@idiocy.org> wrote:
> >
> > I think so. A lot of what people like (smooth scrolling, etc.) would
> > have to be removed.
>
> Weird, this has never worked for me, but maybe I've had it misconfigured
>
> > One more thing to try...
> >
> > modified   src/nsterm.m
> > @@ -8376,7 +8376,13 @@ - (void)unfocusDrawingBuffer
> >    NSTRACE ("[EmacsView unfocusDrawingBuffer]");
> >
> >    [NSGraphicsContext setCurrentContext:nil];
> > -  [self setNeedsDisplay:YES];
> > +  [surface releaseContext];
> > +  [[self layer] setContents:(id)[surface getSurface]];
> > +  [surface performSelectorOnMainThread:@selector (getContext)
> > +                            withObject:nil
> > +                         waitUntilDone:NO];
> > +
> > +  //[self setNeedsDisplay:YES];
> >  }
> >
> >
> > @@ -8513,11 +8519,11 @@ - (void)updateLayer
> >       There's a private method, -[CALayer setContentsChanged], that we
> >       could use to force it, but we shouldn't often get the same
> >       surface twice in a row.  */
> > -  [surface releaseContext];
> > -  [[self layer] setContents:(id)[surface getSurface]];
> > -  [surface performSelectorOnMainThread:@selector (getContext)
> > -                            withObject:nil
> > -                         waitUntilDone:NO];
> > +  // [surface releaseContext];
> > +  // [[self layer] setContents:(id)[surface getSurface]];
> > +  // [surface performSelectorOnMainThread:@selector (getContext)
> > +  //                           withObject:nil
> > +  //                        waitUntilDone:NO];
> >  }
> >  #endif
> >
> >
> > All this does is reduce the time between us deciding we're done with
> > drawing and sending it off to VRAM (although it might not, I'm not
> > entirely sure when updateLayer gets called).
> >
> > I expect this to reduce frame rate, but perhaps it will improve input
> > lag a little.
>
> I don't know if it's something funky with my machine or not but I've
> noticed some stutters with this patch. As in, it appears to miss
> paints. I'll type a character and won't see it until I type something
> else. Is it possible that this patch could cause that?

This stopped, so maybe it was something funky. So far, today, things
feel pretty good from a latency perspective. I haven't measured
anything yet.

Thanks,

Aaron

Re: macOS metal rendering engine in mac port

[Alan Third]

On Tue, May 25, 2021 at 05:32:09PM -0700, Aaron Jensen wrote:
> On Tue, May 25, 2021 at 9:31 AM Aaron Jensen <aaronjensen@gmail.com> wrote:
> >
> > I don't know if it's something funky with my machine or not but I've
> > noticed some stutters with this patch. As in, it appears to miss
> > paints. I'll type a character and won't see it until I type something
> > else. Is it possible that this patch could cause that?
> 
> This stopped, so maybe it was something funky. So far, today, things
> feel pretty good from a latency perspective. I haven't measured
> anything yet.

It probably could, I've seen something similar when I was testing
something or other. It will be bypassing the viewWillDraw code that
forces a redisplay, but I think in theory we shouldn't need it with
this code.

Oh, I suppose that might break the live resizing. But we can work that
out if so.
-- 
Alan Third

Re: macOS metal rendering engine in mac port

[Aaron Jensen]

On Tue, May 25, 2021 at 11:23 PM Alan Third <alan@idiocy.org> wrote:
>
> It probably could, I've seen something similar when I was testing
> something or other. It will be bypassing the viewWillDraw code that
> forces a redisplay, but I think in theory we shouldn't need it with
> this code.
>
> Oh, I suppose that might break the live resizing. But we can work that
> out if so.

Live resizing? I don't see the flicker and if I drag to resize it
remains painted usually. I did see it flash white once. And I think
I've perhaps seen it blank one time today briefly, but I don't
remember what I was doing.

Re: macOS metal rendering engine in mac port

[Aaron Jensen]

On Tue, May 25, 2021 at 11:26 PM Aaron Jensen <aaronjensen@gmail.com> wrote:
>
> On Tue, May 25, 2021 at 11:23 PM Alan Third <alan@idiocy.org> wrote:
> >
> > It probably could, I've seen something similar when I was testing
> > something or other. It will be bypassing the viewWillDraw code that
> > forces a redisplay, but I think in theory we shouldn't need it with
> > this code.
> >
> > Oh, I suppose that might break the live resizing. But we can work that
> > out if so.
>
> Live resizing? I don't see the flicker and if I drag to resize it
> remains painted usually. I did see it flash white once. And I think
> I've perhaps seen it blank one time today briefly, but I don't
> remember what I was doing.

Just did some latency measurements with emacs -Q (my previous ones
were w/ my config)

emacs27-drawing branch: 79.2 62.5 75.0 70.4 (71.775 avg)
emacs28 surface-stuff branch: 66.7 66.7 75.0 70.8 (69.8 avg)
emacs28 surface-stuff branch+last patch: 70.8 75.0 66.7 62.5 (68.75 avg)

Those are similar, if not slightly better than iterm2 latency on my
machine, so that's probably pretty good. The margin of error is going
to be pretty high on those, so I can't definitely say that 28 is
faster.

The scroll-up-benchmark w/o the patch is slightly better from my
limited testing (4.9s vs 5.2s).

Aaron

Re: macOS metal rendering engine in mac port

[Aaron Jensen]

On Tue, May 25, 2021 at 11:23 PM Alan Third <alan@idiocy.org> wrote:
>
> On Tue, May 25, 2021 at 05:32:09PM -0700, Aaron Jensen wrote:
> > On Tue, May 25, 2021 at 9:31 AM Aaron Jensen <aaronjensen@gmail.com> wrote:
> > >
> > > I don't know if it's something funky with my machine or not but I've
> > > noticed some stutters with this patch. As in, it appears to miss
> > > paints. I'll type a character and won't see it until I type something
> > > else. Is it possible that this patch could cause that?
> >
> > This stopped, so maybe it was something funky. So far, today, things
> > feel pretty good from a latency perspective. I haven't measured
> > anything yet.
>
> It probably could, I've seen something similar when I was testing
> something or other. It will be bypassing the viewWillDraw code that
> forces a redisplay, but I think in theory we shouldn't need it with
> this code.
>
> Oh, I suppose that might break the live resizing. But we can work that
> out if so.

I've continued to use this and what I've noticed is that it's during
Zoom screen shares that stalls appear to happen. Zoom eats quite a bit
of CPU while screen sharing and Emacs will occasionally fail to paint
using this patch. When I'm not screen sharing I don't see the issue.
Even when I am, it's infrequent.

Aaron

Re: macOS metal rendering engine in mac port

[Alan Third]

On Fri, May 28, 2021 at 10:39:15AM -0700, Aaron Jensen wrote:
> On Tue, May 25, 2021 at 11:23 PM Alan Third <alan@idiocy.org> wrote:
> >
> > On Tue, May 25, 2021 at 05:32:09PM -0700, Aaron Jensen wrote:
> > > On Tue, May 25, 2021 at 9:31 AM Aaron Jensen <aaronjensen@gmail.com> wrote:
> > > >
> > > > I don't know if it's something funky with my machine or not but I've
> > > > noticed some stutters with this patch. As in, it appears to miss
> > > > paints. I'll type a character and won't see it until I type something
> > > > else. Is it possible that this patch could cause that?
> > >
> > > This stopped, so maybe it was something funky. So far, today, things
> > > feel pretty good from a latency perspective. I haven't measured
> > > anything yet.
> >
> > It probably could, I've seen something similar when I was testing
> > something or other. It will be bypassing the viewWillDraw code that
> > forces a redisplay, but I think in theory we shouldn't need it with
> > this code.
> >
> > Oh, I suppose that might break the live resizing. But we can work that
> > out if so.
> 
> I've continued to use this and what I've noticed is that it's during
> Zoom screen shares that stalls appear to happen. Zoom eats quite a bit
> of CPU while screen sharing and Emacs will occasionally fail to paint
> using this patch. When I'm not screen sharing I don't see the issue.
> Even when I am, it's infrequent.

Hmm, TBH I don't think I'd really recommend this patch over, say,
090ac3556c (the 2nd last commit in scratch/ns/surface-stuff).

Unless it really does make a difference to input lag.

-- 
Alan Third

Re: macOS metal rendering engine in mac port

[Aaron Jensen]

On Fri, May 28, 2021 at 11:32 AM Alan Third <alan@idiocy.org> wrote:
>
> On Fri, May 28, 2021 at 10:39:15AM -0700, Aaron Jensen wrote:
> > On Tue, May 25, 2021 at 11:23 PM Alan Third <alan@idiocy.org> wrote:
> > >
> > > On Tue, May 25, 2021 at 05:32:09PM -0700, Aaron Jensen wrote:
> > > > On Tue, May 25, 2021 at 9:31 AM Aaron Jensen <aaronjensen@gmail.com> wrote:
> > > > >
> > > > > I don't know if it's something funky with my machine or not but I've
> > > > > noticed some stutters with this patch. As in, it appears to miss
> > > > > paints. I'll type a character and won't see it until I type something
> > > > > else. Is it possible that this patch could cause that?
> > > >
> > > > This stopped, so maybe it was something funky. So far, today, things
> > > > feel pretty good from a latency perspective. I haven't measured
> > > > anything yet.
> > >
> > > It probably could, I've seen something similar when I was testing
> > > something or other. It will be bypassing the viewWillDraw code that
> > > forces a redisplay, but I think in theory we shouldn't need it with
> > > this code.
> > >
> > > Oh, I suppose that might break the live resizing. But we can work that
> > > out if so.
> >
> > I've continued to use this and what I've noticed is that it's during
> > Zoom screen shares that stalls appear to happen. Zoom eats quite a bit
> > of CPU while screen sharing and Emacs will occasionally fail to paint
> > using this patch. When I'm not screen sharing I don't see the issue.
> > Even when I am, it's infrequent.
>
> Hmm, TBH I don't think I'd really recommend this patch over, say,
> 090ac3556c (the 2nd last commit in scratch/ns/surface-stuff).
>
> Unless it really does make a difference to input lag.

Okay, I'll run with that for a while. And you think this is better
than the last commit of the surface-stuff branch?

Aaron

Re: macOS metal rendering engine in mac port

[Alan Third]

On Fri, May 28, 2021 at 12:00:43PM -0700, Aaron Jensen wrote:
> >
> > Hmm, TBH I don't think I'd really recommend this patch over, say,
> > 090ac3556c (the 2nd last commit in scratch/ns/surface-stuff).
> >
> > Unless it really does make a difference to input lag.
> 
> Okay, I'll run with that for a while. And you think this is better
> than the last commit of the surface-stuff branch?

¯\_(ツ)_/¯

I think I like the code a lot better, and as far as I can recall
neither you, nor I, were able to detect much difference.

-- 
Alan Third

Re: macOS metal rendering engine in mac port

[Aaron Jensen]

On Fri, May 28, 2021 at 12:29 PM Alan Third <alan@idiocy.org> wrote:
>
> On Fri, May 28, 2021 at 12:00:43PM -0700, Aaron Jensen wrote:
> > >
> > > Hmm, TBH I don't think I'd really recommend this patch over, say,
> > > 090ac3556c (the 2nd last commit in scratch/ns/surface-stuff).
> > >
> > > Unless it really does make a difference to input lag.
> >
> > Okay, I'll run with that for a while. And you think this is better
> > than the last commit of the surface-stuff branch?
>
> ¯\_(ツ)_/¯
>
> I think I like the code a lot better, and as far as I can recall
> neither you, nor I, were able to detect much difference.

Works for me. I can't tell a difference just in typing between
surface-stuff HEAD, HEAD^ or emacs27-drawing.

Eli, could you link me to the merge_face_ref optimization discussion
so I could follow along please?

Thanks,

Aaron

Re: macOS metal rendering engine in mac port

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Fri, 28 May 2021 15:07:27 -0700
> 
> Eli, could you link me to the merge_face_ref optimization discussion
> so I could follow along please?

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41200

Re: macOS metal rendering engine in mac port

[Aaron Jensen]

On Fri, May 28, 2021 at 11:07 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Aaron Jensen <aaronjensen@gmail.com>
> > Date: Fri, 28 May 2021 15:07:27 -0700
> >
> > Eli, could you link me to the merge_face_ref optimization discussion
> > so I could follow along please?
>
>   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41200

Thank you. Wow, that seems to make a huge difference in typing latency feel.

Re: macOS metal rendering engine in mac port

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Sat, 29 May 2021 00:01:31 -0700
> Cc: Alan Third <alan@idiocy.org>, emacs-devel@gnu.org
> 
> On Fri, May 28, 2021 at 11:07 PM Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > > From: Aaron Jensen <aaronjensen@gmail.com>
> > > Date: Fri, 28 May 2021 15:07:27 -0700
> > >
> > > Eli, could you link me to the merge_face_ref optimization discussion
> > > so I could follow along please?
> >
> >   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41200
> 
> Thank you. Wow, that seems to make a huge difference in typing latency feel.

In "emacs -Q" as well?  If so, it again puzzles me how face merging
has such a profound effect on redisplay in your case.  It shouldn't.

Re: macOS metal rendering engine in mac port

[Aaron Jensen]

On Sat, May 29, 2021 at 12:05 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Aaron Jensen <aaronjensen@gmail.com>
> > Date: Sat, 29 May 2021 00:01:31 -0700
> > Cc: Alan Third <alan@idiocy.org>, emacs-devel@gnu.org
> >
> > On Fri, May 28, 2021 at 11:07 PM Eli Zaretskii <eliz@gnu.org> wrote:
> > >
> > > > From: Aaron Jensen <aaronjensen@gmail.com>
> > > > Date: Fri, 28 May 2021 15:07:27 -0700
> > > >
> > > > Eli, could you link me to the merge_face_ref optimization discussion
> > > > so I could follow along please?
> > >
> > >   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41200
> >
> > Thank you. Wow, that seems to make a huge difference in typing latency feel.
>
> In "emacs -Q" as well?  If so, it again puzzles me how face merging
> has such a profound effect on redisplay in your case.  It shouldn't.

emacs -Q never really felt slow in terms of typing latency. In terms
of the scroll benchmark, I got:

w/o patch: 26.8s first run, 3.84s second run
w/ patch: 25.1s first run, 3.6s second run

With my emacs config that has, with everything loaded, 1156 faces, I get:

w/o patch: 18.6s on second run (at least 9s of which are attributed to
TAGGEDP and CONSP from lface_from_face_name_no_resolve)
w/ patch: 6.1s on second run

The impact is drastic.

One thing about my config is I eager load all of the packages I have
installed on idle, so I end up with all of their faces in my face
list. I don't have a massive config (147 packages, it looks like), but
it's apparently big enough.

Re: macOS metal rendering engine in mac port

[Aaron Jensen]

On Sat, May 29, 2021 at 1:52 AM Aaron Jensen <aaronjensen@gmail.com> wrote:
>
> On Sat, May 29, 2021 at 12:05 AM Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > > From: Aaron Jensen <aaronjensen@gmail.com>
> > > Date: Sat, 29 May 2021 00:01:31 -0700
> > > Cc: Alan Third <alan@idiocy.org>, emacs-devel@gnu.org
> > >
> > > On Fri, May 28, 2021 at 11:07 PM Eli Zaretskii <eliz@gnu.org> wrote:
> > > >
> > > > > From: Aaron Jensen <aaronjensen@gmail.com>
> > > > > Date: Fri, 28 May 2021 15:07:27 -0700
> > > > >
> > > > > Eli, could you link me to the merge_face_ref optimization discussion
> > > > > so I could follow along please?
> > > >
> > > >   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41200
> > >
> > > Thank you. Wow, that seems to make a huge difference in typing latency feel.

Oh, and even with my config, with line numbers, in a ruby file, I'm
seeing 60-80ms latency with my measuring app. That's quite a bit
better.

Re: macOS metal rendering engine in mac port

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Sat, 29 May 2021 02:06:18 -0700
> Cc: Alan Third <alan@idiocy.org>, emacs-devel@gnu.org
> 
> Oh, and even with my config, with line numbers, in a ruby file, I'm
> seeing 60-80ms latency with my measuring app.

Compared to what latency without line numbers?  60-80ms is quite a lot
for redisplay, but I don't really have a clear picture of how that
works on NS.

Re: macOS metal rendering engine in mac port

[Alan Third]

On Sat, May 29, 2021 at 12:21:48PM +0300, Eli Zaretskii wrote:
> > From: Aaron Jensen <aaronjensen@gmail.com>
> > Date: Sat, 29 May 2021 02:06:18 -0700
> > Cc: Alan Third <alan@idiocy.org>, emacs-devel@gnu.org
> > 
> > Oh, and even with my config, with line numbers, in a ruby file, I'm
> > seeing 60-80ms latency with my measuring app.
> 
> Compared to what latency without line numbers?  60-80ms is quite a lot
> for redisplay, but I don't really have a clear picture of how that
> works on NS.

FWIW, on my Mac I put some timings into the display code and from the
moment we receive a keyDown notification to the moment we hand off the
drawn buffer to the system for display takes around 3-6ms, so unless
Aaron's system is very different from mine, most of that time is spent
in places we can't do much about.
-- 
Alan Third

Re: macOS metal rendering engine in mac port

[Eli Zaretskii]

> Date: Sat, 29 May 2021 10:35:03 +0100
> From: Alan Third <alan@idiocy.org>
> Cc: Aaron Jensen <aaronjensen@gmail.com>, emacs-devel@gnu.org
> 
> > > Oh, and even with my config, with line numbers, in a ruby file, I'm
> > > seeing 60-80ms latency with my measuring app.
> > 
> > Compared to what latency without line numbers?  60-80ms is quite a lot
> > for redisplay, but I don't really have a clear picture of how that
> > works on NS.
> 
> FWIW, on my Mac I put some timings into the display code and from the
> moment we receive a keyDown notification to the moment we hand off the
> drawn buffer to the system for display takes around 3-6ms, so unless
> Aaron's system is very different from mine, most of that time is spent
> in places we can't do much about.

The question is: is this 3 to 6ms delay affected in any way by turning
on line numbers?  If not, then not only don't I understand why line
numbers affect the latency, I also don't understand how come the
number of faces affects that.

Re: macOS metal rendering engine in mac port

[Aaron Jensen]

On Sat, May 29, 2021 at 2:35 AM Alan Third <alan@idiocy.org> wrote:
>
> FWIW, on my Mac I put some timings into the display code and from the
> moment we receive a keyDown notification to the moment we hand off the
> drawn buffer to the system for display takes around 3-6ms, so unless
> Aaron's system is very different from mine, most of that time is spent
> in places we can't do much about.

On Sat, May 29, 2021 at 2:21 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> Compared to what latency without line numbers?  60-80ms is quite a lot
> for redisplay, but I don't really have a clear picture of how that
> works on NS.

Often around 90-100ms. I'm actually measuring using a high speed
camera (iphone) and comparing the physical keydown time, so it
includes keyboard controller time, USB signal time, OS interrupt
handling, monitor pixel latency, etc.

Oh and I was mistaken on my face count, that was actually the position
of the line-number face. My face count is 1234 at the moment.

On Sat, May 29, 2021 at 2:41 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> The question is: is this 3 to 6ms delay affected in any way by turning
> on line numbers?  If not, then not only don't I understand why line
> numbers affect the latency, I also don't understand how come the
> number of faces affects that.

As I've described earlier in this thread, turning on line numbers
massively increases the number of calls to
lface_from_face_name_no_resolve specifically with faces that are very
late in my list of faces. This is a profile of me typing about 10
characters with the profile tree reversed and a lower debug symbol
setting (not sure what, i built this with homebrew) so it's not
showing macros:

https://cln.sh/9Fsiqe

If I slice that to only include calls from maybe_produce_line_number,
I get 203ms to assq_no_quit.

This means 37% of the CPU time emacs spends when I'm typing is in
assq_no_quit for face lookup.

It also means that 21% of the CPU time emacs spends when I'm typing is
in assq_no_quit for face lookup specifically for line numbers. So,
line numbers account for 57% of the CPU time spent doing face lookups
on my machine.

So, perhaps the question is, why is assq_no_quit such a hot spot for
me on my machine when there are over 1000 faces in the list to scan?
I'm not sure I could answer that, but it's intuitive that the more
faces one has, the more time a machine would spend doing linear scans,
and when those scans are done a massive number of times, it's not
surprising to see them show up on profiles.

Another data point, without the patch:

(benchmark 500000 '(assoc 'line-number face-new-frame-defaults))

On my emacs config: 2.7s
emacs -Q: 0.14s

And with the patch:

(benchmark 500000 '(gethash 'line-number face--new-frame-defaults))

My config: 0.06s
emacs -Q: 0.06s

500k is roughly how many *extra* calls to
lface_from_face_name_no_resolve are made during the scroll up
benchmark when line numbers are enabled.

I'm really not seeing anything mysterious about this, but I don't have
the context you have so I could be missing something. It looks like a
case of O(N) scales worse than O(log n). I just happen to have an N
that is 10x the N with emacs -Q.

Aaron

> --
> Alan Third

Re: macOS metal rendering engine in mac port

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Sat, 29 May 2021 09:18:07 -0700
> 
> On Sat, May 29, 2021 at 2:21 AM Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > Compared to what latency without line numbers?  60-80ms is quite a lot
> > for redisplay, but I don't really have a clear picture of how that
> > works on NS.
> 
> Often around 90-100ms.

I don't understand: you get 60-80ms _with_ line numbers and 90-100ms
_without_ line numbers?  That's the opposite of what I would expect.

> As I've described earlier in this thread, turning on line numbers
> massively increases the number of calls to
> lface_from_face_name_no_resolve

And as I've explained to you, "massively" is an exaggeration.  The
number of face merges increases roughly two-fold when you turn on line
numbers.

> specifically with faces that are very late in my list of faces.

Which faces are those?  If they are line-number faces, does it mean
that turning on display-line-numbers-mode earlier makes redisplay
faster for you?

> If I slice that to only include calls from maybe_produce_line_number,
> I get 203ms to assq_no_quit.

Not sure I understand: 230ms for a _single_ call to assq_no_quit?  If
not, for how many calls?

> This means 37% of the CPU time emacs spends when I'm typing is in
> assq_no_quit for face lookup.

37% by itself is not a catastrophe.  Redisplay performs many face
merges.

> So, perhaps the question is, why is assq_no_quit such a hot spot for
> me on my machine when there are over 1000 faces in the list to scan?

Good question.

> Another data point, without the patch:
> 
> (benchmark 500000 '(assoc 'line-number face-new-frame-defaults))
> 
> On my emacs config: 2.7s
> emacs -Q: 0.14s

That's 5.4 microseconds per call.  How is this consistent with the
230ms figure above?

> And with the patch:
> 
> (benchmark 500000 '(gethash 'line-number face--new-frame-defaults))
> 
> My config: 0.06s
> emacs -Q: 0.06s

That's not surprising.  But what does it tell you about the actual use
case which we were discussing?

> I'm really not seeing anything mysterious about this, but I don't have
> the context you have so I could be missing something. It looks like a
> case of O(N) scales worse than O(log n). I just happen to have an N
> that is 10x the N with emacs -Q.

Linear search should be linear in the number of faces in the list.

Re: macOS metal rendering engine in mac port

[Aaron Jensen]

On Sat, May 29, 2021 at 9:49 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Aaron Jensen <aaronjensen@gmail.com>
> > Date: Sat, 29 May 2021 09:18:07 -0700
> >
> > On Sat, May 29, 2021 at 2:21 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > >
> > > Compared to what latency without line numbers?  60-80ms is quite a lot
> > > for redisplay, but I don't really have a clear picture of how that
> > > works on NS.
> >
> > Often around 90-100ms.
>
> I don't understand: you get 60-80ms _with_ line numbers and 90-100ms
> _without_ line numbers?  That's the opposite of what I would expect.

Ugh, my reading comprehension is off this morning. That was the
without _patch_ timing I shared. Turning off line numbers when the
patch is enabled likely won't make a difference. I can't measure that
right now.

> > As I've described earlier in this thread, turning on line numbers
> > massively increases the number of calls to
> > lface_from_face_name_no_resolve
>
> And as I've explained to you, "massively" is an exaggeration.  The
> number of face merges increases roughly two-fold when you turn on line
> numbers.

4.5x more calls to lface_from_face_name_no_resolve. Exaggeration or
not, it's significant.

> > specifically with faces that are very late in my list of faces.
>
> Which faces are those?  If they are line-number faces, does it mean
> that turning on display-line-numbers-mode earlier makes redisplay
> faster for you?

Yes, line number faces. You mean later so that they're nearer to the
head of the list? I'm not sure how to test that as the faces get added
even w/o enabling line number mode afaict. I also don't know how to
modify a frame's face alist and when I tried modifying
face-new-frame-defaults and creating a new frame it didn't appear to
make a difference.

> > If I slice that to only include calls from maybe_produce_line_number,
> > I get 203ms to assq_no_quit.
>
> Not sure I understand: 230ms for a _single_ call to assq_no_quit?  If
> not, for how many calls?

No. I don't know how many, but some multiple of 500k. I haven't added
a count printer in there yet.

> > This means 37% of the CPU time emacs spends when I'm typing is in
> > assq_no_quit for face lookup.
>
> 37% by itself is not a catastrophe.  Redisplay performs many face
> merges.

Well, it's worth mentioning that I'm being persnickety here. Most
people probably wouldn't notice the latency difference, but I can feel
it and it's frustrating. Here is a profile from a single key press
using my config w/o the patch:

https://cln.sh/HqVzJv

It's reversed, but you can see 15ms spent in assq_no_quit. For some
reason, that's enough to put it right over the edge of what I can feel
when I type.

> > So, perhaps the question is, why is assq_no_quit such a hot spot for
> > me on my machine when there are over 1000 faces in the list to scan?
>
> Good question.
>
> > Another data point, without the patch:
> >
> > (benchmark 500000 '(assoc 'line-number face-new-frame-defaults))
> >
> > On my emacs config: 2.7s
> > emacs -Q: 0.14s
>
> That's 5.4 microseconds per call.  How is this consistent with the
> 230ms figure above?

Because, as I mentioned below, 500k is the same number of times
lface_from_face_name_no_resolve is called, which is the thing that's
calling assq_no_quit.

> > And with the patch:
> >
> > (benchmark 500000 '(gethash 'line-number face--new-frame-defaults))
> >
> > My config: 0.06s
> > emacs -Q: 0.06s
>
> That's not surprising.  But what does it tell you about the actual use
> case which we were discussing?

It tells me that in the scroll benchmark I add over 2s to my time just
because of face merging and most of that time is due to enabling line
numbers.

> > I'm really not seeing anything mysterious about this, but I don't have
> > the context you have so I could be missing something. It looks like a
> > case of O(N) scales worse than O(log n). I just happen to have an N
> > that is 10x the N with emacs -Q.
>
> Linear search should be linear in the number of faces in the list.

Well, to be precise, it's linear in the position of the thing found,
which is relevant when most of the calls are for the same 2 elements.

Re: macOS metal rendering engine in mac port

[Aaron Jensen]

On Sat, May 29, 2021 at 10:05 AM Aaron Jensen <aaronjensen@gmail.com> wrote:
>
> Well, it's worth mentioning that I'm being persnickety here. Most
> people probably wouldn't notice the latency difference, but I can feel
> it and it's frustrating. Here is a profile from a single key press
> using my config w/o the patch:
>
> https://cln.sh/HqVzJv
>
> It's reversed, but you can see 15ms spent in assq_no_quit. For some
> reason, that's enough to put it right over the edge of what I can feel
> when I type.

Here's a comparison of typing a single character with my config. On
the left is with line numbers enabled. On the right is with them
disabled. Again, these trees are reversed.

https://cln.sh/W9cfWv

Re: macOS metal rendering engine in mac port

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Sat, 29 May 2021 10:20:53 -0700
> Cc: Alan Third <alan@idiocy.org>, emacs-devel@gnu.org
> 
> Here's a comparison of typing a single character with my config. On
> the left is with line numbers enabled. On the right is with them
> disabled. Again, these trees are reversed.

So it's a difference of 10ms, and you are able to feel such a small
difference?  AFAIK, it's way below the threshold of human's ability to
perceive time intervals.  Anything below 100ms is intangible.

Or did I misunderstand the profile?

Re: macOS metal rendering engine in mac port

[Dmitry Gutov]

On 29.05.2021 20:43, Eli Zaretskii wrote:
> So it's a difference of 10ms, and you are able to feel such a small
> difference?  AFAIK, it's way below the threshold of human's ability to
> perceive time intervals.  Anything below 100ms is intangible.

That's not quite true: 100ms might be the limit of human reaction to 
unanticipated events, but if you're doing something repeatedly, the 
delays become easier to notice.

I don't know about 10ms exactly, but 20-30ms - definitely. It will annoy 
some people more than others, but it creates subconscious impression 
either way. We have just recently fixes a related bug in Company 
(regarding increased visual latencies), with multiple reporters and 
benchmarks.

Re: macOS metal rendering engine in mac port

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 29 May 2021 21:00:42 +0300
> Cc: alan@idiocy.org, emacs-devel@gnu.org
> 
> On 29.05.2021 20:43, Eli Zaretskii wrote:
> > So it's a difference of 10ms, and you are able to feel such a small
> > difference?  AFAIK, it's way below the threshold of human's ability to
> > perceive time intervals.  Anything below 100ms is intangible.
> 
> That's not quite true: 100ms might be the limit of human reaction to 
> unanticipated events

No, not "reaction", "perception".  (Reaction to unanticipated events
is much slower, 1 to 2 sec.  Reaction to anticipated events can be
around 250ms.  But we are not talking about reaction, because
perceiving a delay doesn't require any reaction.)

This:

  https://www.britannica.com/science/time-perception/Perceived-duration

says 0.1 sec of visual experience is needed to perceive time duration.
And there are other similar sources.  It is also consistent with my
own experience, from the time when I measure performance of
bidirectional display and compared it with my subjective notion of
"delay": anything below 100ms was barely tangible, anything below 50ms
was perceived as "instantaneous".

Re: macOS metal rendering engine in mac port

[Dmitry Gutov]

On 29.05.2021 21:15, Eli Zaretskii wrote:
> This:
> 
>    https://www.britannica.com/science/time-perception/Perceived-duration
> 
> says 0.1 sec of visual experience is needed to perceive time duration.
> And there are other similar sources.  It is also consistent with my
> own experience, from the time when I measure performance of
> bidirectional display and compared it with my subjective notion of
> "delay": anything below 100ms was barely tangible, anything below 50ms
> was perceived as "instantaneous".

I think repeating the same action multiple times can fine-tune one's 
perception. Either way, perhaps we can agree that the extra 10-20ms, 
even if hard to notice by themselves, can move the perception of some 
compound event from "instantaneous" to "tangible".

Here's that bug I was referring to anyway: 
https://github.com/company-mode/company-mode/issues/1073

Re: macOS metal rendering engine in mac port

[Stefan Monnier]

> bidirectional display and compared it with my subjective notion of
> "delay": anything below 100ms was barely tangible, anything below 50ms
> was perceived as "instantaneous".

The "rule of thumb" that I internalized over the years in my model of
the world is that a "key press to display" of ~100ms is perceived by
most people as "almost but not quite instantaneous" and only once you
get below 50ms is it really perceived as instantaneous by most people.

Take it with a large grain of salt, tho because I don't know where I got
this from, really, and I'm not particularly interested in this subject
(my "Emacs built with -Og and all debugging assertions, plus extra ones
I added over the years" running on my rather old machines often has
delays significantly higher than that; I have a fairly high tolerance
for those things ;-)


        Stefan

Re: macOS metal rendering engine in mac port

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Dmitry Gutov <dgutov@yandex.ru>,  alan@idiocy.org,
>   aaronjensen@gmail.com,  emacs-devel@gnu.org
> Date: Sat, 29 May 2021 15:06:43 -0400
> 
> The "rule of thumb" that I internalized over the years in my model of
> the world is that a "key press to display" of ~100ms is perceived by
> most people as "almost but not quite instantaneous" and only once you
> get below 50ms is it really perceived as instantaneous by most people.

That matches my experience as well.

Re: macOS metal rendering engine in mac port

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Sat, 29 May 2021 10:05:51 -0700
> Cc: Alan Third <alan@idiocy.org>, emacs-devel@gnu.org
> 
> On Sat, May 29, 2021 at 9:49 AM Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > > From: Aaron Jensen <aaronjensen@gmail.com>
> > > Date: Sat, 29 May 2021 09:18:07 -0700
> > >
> > > On Sat, May 29, 2021 at 2:21 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > > >
> > > > Compared to what latency without line numbers?  60-80ms is quite a lot
> > > > for redisplay, but I don't really have a clear picture of how that
> > > > works on NS.
> > >
> > > Often around 90-100ms.
> >
> > I don't understand: you get 60-80ms _with_ line numbers and 90-100ms
> > _without_ line numbers?  That's the opposite of what I would expect.
> 
> Ugh, my reading comprehension is off this morning. That was the
> without _patch_ timing I shared. Turning off line numbers when the
> patch is enabled likely won't make a difference. I can't measure that
> right now.

I think we might be mis-communicating.  You said:

> Oh, and even with my config, with line numbers, in a ruby file, I'm
> seeing 60-80ms latency with my measuring app. That's quite a bit
> better.

(Was this with or without the hash patch applied?)

In response I asked:

> Compared to what latency without line numbers?  60-80ms is quite a lot
> for redisplay, but I don't really have a clear picture of how that
> works on NS.

I wanted to know the latency _without_ line numbers in the same setup
where with line numbers you see 60-80ms.  I'm not sure what you wrote
above answers that question.

> > > As I've described earlier in this thread, turning on line numbers
> > > massively increases the number of calls to
> > > lface_from_face_name_no_resolve
> >
> > And as I've explained to you, "massively" is an exaggeration.  The
> > number of face merges increases roughly two-fold when you turn on line
> > numbers.
> 
> 4.5x more calls to lface_from_face_name_no_resolve. Exaggeration or
> not, it's significant.

Its being significant is what surprises me.  The linear search in
assq_no_quit should be very fast, as it requires just a few machine
instructions per member.  You yourself say your profile says it takes
15ms to call that function 500k times.  How can extra 15ms be so
significant?

> It's reversed, but you can see 15ms spent in assq_no_quit. For some
> reason, that's enough to put it right over the edge of what I can feel
> when I type.

I don't understand this.  I think there's some other factor at work
here.

Is it possible that many of the 1200 faces you have inherit from other
faces, perhaps recursively?

> > > I'm really not seeing anything mysterious about this, but I don't have
> > > the context you have so I could be missing something. It looks like a
> > > case of O(N) scales worse than O(log n). I just happen to have an N
> > > that is 10x the N with emacs -Q.
> >
> > Linear search should be linear in the number of faces in the list.
> 
> Well, to be precise, it's linear in the position of the thing found,
> which is relevant when most of the calls are for the same 2 elements.

But if these faces are always at the same place near the end of the
list, then adding more faces should indeed produce a linear effect,
right?

Re: macOS metal rendering engine in mac port

[Aaron Jensen]

On Sat, May 29, 2021 at 10:34 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Aaron Jensen <aaronjensen@gmail.com>
> > Date: Sat, 29 May 2021 10:05:51 -0700
> > Cc: Alan Third <alan@idiocy.org>, emacs-devel@gnu.org
> >
> > On Sat, May 29, 2021 at 9:49 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > >
> > > > From: Aaron Jensen <aaronjensen@gmail.com>
> > > > Date: Sat, 29 May 2021 09:18:07 -0700
> > > >
> > > > On Sat, May 29, 2021 at 2:21 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > > > >
> > > > > Compared to what latency without line numbers?  60-80ms is quite a lot
> > > > > for redisplay, but I don't really have a clear picture of how that
> > > > > works on NS.
> > > >
> > > > Often around 90-100ms.
> > >
> > > I don't understand: you get 60-80ms _with_ line numbers and 90-100ms
> > > _without_ line numbers?  That's the opposite of what I would expect.
> >
> > Ugh, my reading comprehension is off this morning. That was the
> > without _patch_ timing I shared. Turning off line numbers when the
> > patch is enabled likely won't make a difference. I can't measure that
> > right now.
>
> I think we might be mis-communicating.  You said:
>
> > Oh, and even with my config, with line numbers, in a ruby file, I'm
> > seeing 60-80ms latency with my measuring app. That's quite a bit
> > better.
>
> (Was this with or without the hash patch applied?)

It was with the patch. I was primarily reporting that for Alan's
benefit as he and I had been discussing those latency numbers.

> In response I asked:
>
> > Compared to what latency without line numbers?  60-80ms is quite a lot
> > for redisplay, but I don't really have a clear picture of how that
> > works on NS.
>
> I wanted to know the latency _without_ line numbers in the same setup
> where with line numbers you see 60-80ms.  I'm not sure what you wrote
> above answers that question.

I didn't, because I hadn't measured it yet. I just measured it and
it's very similar. This measurement technique is very imprecise, so I
have to take several measurements. I can't measure a difference
between line numbers and not when the hash patch is applied.

> > > > As I've described earlier in this thread, turning on line numbers
> > > > massively increases the number of calls to
> > > > lface_from_face_name_no_resolve
> > >
> > > And as I've explained to you, "massively" is an exaggeration.  The
> > > number of face merges increases roughly two-fold when you turn on line
> > > numbers.
> >
> > 4.5x more calls to lface_from_face_name_no_resolve. Exaggeration or
> > not, it's significant.
>
> Its being significant is what surprises me.  The linear search in
> assq_no_quit should be very fast, as it requires just a few machine
> instructions per member.  You yourself say your profile says it takes
> 15ms to call that function 500k times.  How can extra 15ms be so
> significant?

I did not say this. 500k times, according to the benchmarks I
provided, take over 2s. It's only 15ms to do 500k _hash lookups_.

> > It's reversed, but you can see 15ms spent in assq_no_quit. For some
> > reason, that's enough to put it right over the edge of what I can feel
> > when I type.
>
> I don't understand this.  I think there's some other factor at work
> here.
>
> Is it possible that many of the 1200 faces you have inherit from other
> faces, perhaps recursively?

My theme is set up like this:
https://github.com/aaronjensen/nano-emacs/blob/master/nano-theme.el

I don't know if I'm doing something wrong in there, I copied it from
the nano project. I know it's atypical to not use a theme.

> > > > I'm really not seeing anything mysterious about this, but I don't have
> > > > the context you have so I could be missing something. It looks like a
> > > > case of O(N) scales worse than O(log n). I just happen to have an N
> > > > that is 10x the N with emacs -Q.
> > >
> > > Linear search should be linear in the number of faces in the list.
> >
> > Well, to be precise, it's linear in the position of the thing found,
> > which is relevant when most of the calls are for the same 2 elements.
>
> But if these faces are always at the same place near the end of the
> list, then adding more faces should indeed produce a linear effect,
> right?

Yes, a linear effect compounded by a large number of calls. That said,
it looks like the effect is 2x what I'd expect given the difference
between face counts. So yes, there may be something else at play. I'd
have to actually put a count in assq_no_quit to see if it's being
called more times than I'd expect.

About perceiving typing latency, have you read this article:
https://pavelfatin.com/typing-with-pleasure/

It's what finally helped me understand what I was perceiving many years ago.

Aaron

Re: macOS metal rendering engine in mac port

[Aaron Jensen]

On Sat, May 29, 2021 at 11:22 AM Aaron Jensen <aaronjensen@gmail.com> wrote:
>
> About perceiving typing latency, have you read this article:
> https://pavelfatin.com/typing-with-pleasure/
>
> It's what finally helped me understand what I was perceiving many years ago.

In particular, this video: https://www.youtube.com/watch?v=vOvQCPLkPt4

It demonstrates a drawing app, but the same ideas apply to typing.

Re: macOS metal rendering engine in mac port

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Sat, 29 May 2021 11:22:06 -0700
> Cc: Alan Third <alan@idiocy.org>, emacs-devel@gnu.org
> 
> > Its being significant is what surprises me.  The linear search in
> > assq_no_quit should be very fast, as it requires just a few machine
> > instructions per member.  You yourself say your profile says it takes
> > 15ms to call that function 500k times.  How can extra 15ms be so
> > significant?
> 
> I did not say this. 500k times, according to the benchmarks I
> provided, take over 2s. It's only 15ms to do 500k _hash lookups_.

OK, but still: assq_no_quit should be very fast.

> > Is it possible that many of the 1200 faces you have inherit from other
> > faces, perhaps recursively?
> 
> My theme is set up like this:
> https://github.com/aaronjensen/nano-emacs/blob/master/nano-theme.el

I see a lot of :inherit there.  I'm quite sure this exacerbates the
problem, as each :inherit needs to recursively search for and access
the attributes of the parent face.

> About perceiving typing latency, have you read this article:
> https://pavelfatin.com/typing-with-pleasure/

Yes.

Re: macOS metal rendering engine in mac port

[Aaron Jensen]

On Sat, May 29, 2021 at 11:40 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Aaron Jensen <aaronjensen@gmail.com>
> > Date: Sat, 29 May 2021 11:22:06 -0700
> > Cc: Alan Third <alan@idiocy.org>, emacs-devel@gnu.org
> >
> > > Its being significant is what surprises me.  The linear search in
> > > assq_no_quit should be very fast, as it requires just a few machine
> > > instructions per member.  You yourself say your profile says it takes
> > > 15ms to call that function 500k times.  How can extra 15ms be so
> > > significant?
> >
> > I did not say this. 500k times, according to the benchmarks I
> > provided, take over 2s. It's only 15ms to do 500k _hash lookups_.
>
> OK, but still: assq_no_quit should be very fast.

Sure, it's fast when you call it once, but it's not being called once.
It's being called enough times that it adds 10ms to every key press
when I have line numbers on and 1000+ faces.

> > > Is it possible that many of the 1200 faces you have inherit from other
> > > faces, perhaps recursively?
> >
> > My theme is set up like this:
> > https://github.com/aaronjensen/nano-emacs/blob/master/nano-theme.el
>
> I see a lot of :inherit there.  I'm quite sure this exacerbates the
> problem, as each :inherit needs to recursively search for and access
> the attributes of the parent face.

It only navigates the parent when the face matches, yes? So in my
case, line-number inherits from shadow, which inherits from
nano-face-faded. So I add an extra hop in there for each of those face
lookups.

> > About perceiving typing latency, have you read this article:
> > https://pavelfatin.com/typing-with-pleasure/
>
> Yes.

Okay, it sounds like you and I just fall into different personal
perception/preferences categories.

In any case, the hash table lookup makes a perceptible and much
appreciated difference for me, so thank you and thanks to everyone
else who contributed to that. Also, thanks Alan for the changes in
surface stuff, they seem to help as well.

Thanks,

Aaron

Re: macOS metal rendering engine in mac port

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Sat, 29 May 2021 12:30:49 -0700
> Cc: Alan Third <alan@idiocy.org>, emacs-devel@gnu.org
> 
> > OK, but still: assq_no_quit should be very fast.
> 
> Sure, it's fast when you call it once, but it's not being called once.
> It's being called enough times that it adds 10ms to every key press
> when I have line numbers on and 1000+ faces.

In a 64-bit optimized build, assq_no_quit's loop body is just 10
machine instructions.  With 1200 faces, searching all of them once
should take something like 500 nanoseconds, i.e. 0.5 microsecond.
Does this match the times you see and the number of times the function
is called?

Also, please note that typing a single character redisplays just one
line, the one where point is.  That perhaps needs to merge 4 or 5
faces.  So I'm not sure how come this could add 10ms to every
keypress: you'd need 20,000 calls of assq_no_quit to account for 10ms.
How come we call assq_no_quit 20k times when processing insertion of a
single character?

> > > My theme is set up like this:
> > > https://github.com/aaronjensen/nano-emacs/blob/master/nano-theme.el
> >
> > I see a lot of :inherit there.  I'm quite sure this exacerbates the
> > problem, as each :inherit needs to recursively search for and access
> > the attributes of the parent face.
> 
> It only navigates the parent when the face matches, yes?

Which face matches what?

Emacs needs to access the parent face each time it merges the
inheriting face with another one, because it needs to resolve all the
attributes of each face it merges.

Re: macOS metal rendering engine in mac port

[Aaron Jensen]

On Sat, May 29, 2021 at 1:03 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Aaron Jensen <aaronjensen@gmail.com>
> > Date: Sat, 29 May 2021 12:30:49 -0700
> > Cc: Alan Third <alan@idiocy.org>, emacs-devel@gnu.org
> >
> > > OK, but still: assq_no_quit should be very fast.
> >
> > Sure, it's fast when you call it once, but it's not being called once.
> > It's being called enough times that it adds 10ms to every key press
> > when I have line numbers on and 1000+ faces.
>
> In a 64-bit optimized build, assq_no_quit's loop body is just 10
> machine instructions.  With 1200 faces, searching all of them once
> should take something like 500 nanoseconds, i.e. 0.5 microsecond.
> Does this match the times you see and the number of times the function
> is called?
>
> Also, please note that typing a single character redisplays just one
> line, the one where point is.  That perhaps needs to merge 4 or 5
> faces.  So I'm not sure how come this could add 10ms to every
> keypress: you'd need 20,000 calls of assq_no_quit to account for 10ms.
> How come we call assq_no_quit 20k times when processing insertion of a
> single character?

So with a single keypress I see:

6,000 lface_from_face_name_no_resolve
19,000 assq_no_quit

So yeah, that about accounts for 10ms

> > > > My theme is set up like this:
> > > > https://github.com/aaronjensen/nano-emacs/blob/master/nano-theme.el
> > >
> > > I see a lot of :inherit there.  I'm quite sure this exacerbates the
> > > problem, as each :inherit needs to recursively search for and access
> > > the attributes of the parent face.
> >
> > It only navigates the parent when the face matches, yes?
>
> Which face matches what?
>
> Emacs needs to access the parent face each time it merges the
> inheriting face with another one, because it needs to resolve all the
> attributes of each face it merges.

Sorry, I mean having 900 new faces with inherits shouldn't change the
time it takes to merge faces for a single face. In other words,
inherit only adds instructions when the face being merged has
inherits. It doesn't add it when 900 not-being-merged faces have
inherits.

Re: macOS metal rendering engine in mac port

[Aaron Jensen]

On Sat, May 29, 2021 at 2:03 PM Aaron Jensen <aaronjensen@gmail.com> wrote:
>
> On Sat, May 29, 2021 at 1:03 PM Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > > From: Aaron Jensen <aaronjensen@gmail.com>
> > > Date: Sat, 29 May 2021 12:30:49 -0700
> > > Cc: Alan Third <alan@idiocy.org>, emacs-devel@gnu.org
> > >
> > > > OK, but still: assq_no_quit should be very fast.
> > >
> > > Sure, it's fast when you call it once, but it's not being called once.
> > > It's being called enough times that it adds 10ms to every key press
> > > when I have line numbers on and 1000+ faces.
> >
> > In a 64-bit optimized build, assq_no_quit's loop body is just 10
> > machine instructions.  With 1200 faces, searching all of them once
> > should take something like 500 nanoseconds, i.e. 0.5 microsecond.
> > Does this match the times you see and the number of times the function
> > is called?
> >
> > Also, please note that typing a single character redisplays just one
> > line, the one where point is.  That perhaps needs to merge 4 or 5
> > faces.  So I'm not sure how come this could add 10ms to every
> > keypress: you'd need 20,000 calls of assq_no_quit to account for 10ms.
> > How come we call assq_no_quit 20k times when processing insertion of a
> > single character?
>
> So with a single keypress I see:
>
> 6,000 lface_from_face_name_no_resolve
> 19,000 assq_no_quit
>
> So yeah, that about accounts for 10ms

If I'm quicker on the count, I see only about 9,000 assq_no_quit.
Immediately thereafter another 10,000 or so go by, so maybe I can only
attribute 9,000 w/ a keypress.

There are only about 4,000 when line numbers are disabled using the
same config. (all this is without the hash patch)

Re: macOS metal rendering engine in mac port

[Aaron Jensen]

Here's another benchmark:

(defun type-benchmark ()
       (interactive)
       (let ((oldgc gcs-done)
             (oldtime (float-time)))
         (cl-loop for x from 1 to 300 do
                  (insert-char ?j) (redisplay))
         (message "GCs: %d Elapsed time: %f seconds"
                    (- gcs-done oldgc) (- (float-time) oldtime))))

All with Surface stuff branch and -O2.

With Native Comp, Hash, and line numbers: 1630ms
With Native Comp, Hash, and no line numbers: 874ms

With No Native Comp, Hash, and line numbers: 1712ms
With No Native Comp, Hash, and no line numbers: 900ms

With No Native Comp, alist, and line numbers: 2368ms
With No Native Comp, alist, and no line numbers: 1062ms

With Native Comp, alist, and line numbers: 3321ms
With Native Comp, alist, and no line numbers: 1333ms


So according to this, native comp is slower for me in this typing test
but only if alists are used? That's surprising right?

Re: macOS metal rendering engine in mac port

[Aaron Jensen]

On Sat, May 29, 2021 at 2:40 PM Aaron Jensen <aaronjensen@gmail.com> wrote:
>
> Here's another benchmark:
>
> (defun type-benchmark ()
>        (interactive)
>        (let ((oldgc gcs-done)
>              (oldtime (float-time)))
>          (cl-loop for x from 1 to 300 do
>                   (insert-char ?j) (redisplay))
>          (message "GCs: %d Elapsed time: %f seconds"
>                     (- gcs-done oldgc) (- (float-time) oldtime))))
>
> All with Surface stuff branch and -O2.
>
> With Native Comp, Hash, and line numbers: 1630ms
> With Native Comp, Hash, and no line numbers: 874ms
>
> With No Native Comp, Hash, and line numbers: 1712ms
> With No Native Comp, Hash, and no line numbers: 900ms
>
> With No Native Comp, alist, and line numbers: 2368ms
> With No Native Comp, alist, and no line numbers: 1062ms
>
> With Native Comp, alist, and line numbers: 3321ms
> With Native Comp, alist, and no line numbers: 1333ms
>
>
> So according to this, native comp is slower for me in this typing test
> but only if alists are used? That's surprising right?

Okay, thankfully I can no longer reproduce the difference between
native and not with alists. I must have had something else built that
I ran that on. No idea what. But I built both fresh and they're both
similar to the native comp numbers I posted. So, please disregard the
"No Native Comp, alist" numbers. Native comp doesn't appear to make
much of a difference whether or not I'm using hash or alist.

Re: macOS metal rendering engine in mac port

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Sat, 29 May 2021 21:44:58 -0700
> Cc: Alan Third <alan@idiocy.org>, emacs-devel@gnu.org
> 
> Native comp doesn't appear to make much of a difference whether or
> not I'm using hash or alist.

That's expected, since the code involved in this is all in C anyway.

Re: macOS metal rendering engine in mac port

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Sat, 29 May 2021 14:40:09 -0700
> Cc: Alan Third <alan@idiocy.org>, emacs-devel@gnu.org
> 
> Here's another benchmark:
> 
> (defun type-benchmark ()
>        (interactive)
>        (let ((oldgc gcs-done)
>              (oldtime (float-time)))
>          (cl-loop for x from 1 to 300 do
>                   (insert-char ?j) (redisplay))
>          (message "GCs: %d Elapsed time: %f seconds"
>                     (- gcs-done oldgc) (- (float-time) oldtime))))

In a buffer visiting what file?

Re: macOS metal rendering engine in mac port

[Aaron Jensen]

On Sat, May 29, 2021 at 11:27 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Aaron Jensen <aaronjensen@gmail.com>
> > Date: Sat, 29 May 2021 14:40:09 -0700
> > Cc: Alan Third <alan@idiocy.org>, emacs-devel@gnu.org
> >
> > Here's another benchmark:
> >
> > (defun type-benchmark ()
> >        (interactive)
> >        (let ((oldgc gcs-done)
> >              (oldtime (float-time)))
> >          (cl-loop for x from 1 to 300 do
> >                   (insert-char ?j) (redisplay))
> >          (message "GCs: %d Elapsed time: %f seconds"
> >                     (- gcs-done oldgc) (- (float-time) oldtime))))
>
> In a buffer visiting what file?

That was in my private ruby file that I've been doing most of my testing in.

If I run the test on line 499 of xdisp.c I get:

Native, hash, no line numbers: 3756ms
Native, hash, line numbers: 4185ms

Native, alist, no line numbers: 4810ms
Native, alist, line numbers: 7173ms


> In "emacs -Q" I get only about 180 calls to
> lface_from_face_name_no_resolve when I type a single character,
> depending on where in xdisp.c I do that.  How many calls do you see
> when you just move the cursor to the left or to the right one
> character position?

On line 500 of xdisp.c, less than 100 with line numbers off, ~1300
with line numbers on.
I have 48 lines visible, a mode line with nothing in it, and a header line.

If I disable my theme, I get about 9 moving to the right and 2 to the
left with line numbers on. Yikes.

It's not my faces though, it's my header line that's causing that many
calls, possibly because it's triggering a redraw because the column
changed? I'm not sure how mode/header lines work when they update.

https://github.com/aaronjensen/nano-emacs/blob/master/nano-modeline.el

To see the impacts of my theme when line numbers are on:

Theme on: 7173ms
Header line off: 6900ms
Faces default: 6100ms
Header off and faces default: 5682ms

For comparison, header off and faces default with line numbers off: 3804ms

This does tell me I want to stop using inheritance in my theme, but it
won't make as big of a difference w/ the hash patch I imagine.

Re: macOS metal rendering engine in mac port

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Sun, 30 May 2021 00:04:43 -0700
> Cc: Alan Third <alan@idiocy.org>, emacs-devel@gnu.org
> 
> If I run the test on line 499 of xdisp.c I get:
> 
> Native, hash, no line numbers: 3756ms
> Native, hash, line numbers: 4185ms
> 
> Native, alist, no line numbers: 4810ms
> Native, alist, line numbers: 7173ms

In an unoptimized build, "emacs -Q", without native-compilation, I get
26.39 and 27.22 sec, respectively.

> On line 500 of xdisp.c, less than 100 with line numbers off, ~1300
> with line numbers on.
> I have 48 lines visible, a mode line with nothing in it, and a header line.
> 
> If I disable my theme, I get about 9 moving to the right and 2 to the
> left with line numbers on. Yikes.

Indeed.

> It's not my faces though, it's my header line that's causing that many
> calls, possibly because it's triggering a redraw because the column
> changed? I'm not sure how mode/header lines work when they update.

You have the column displayed on your header-line?

> Theme on: 7173ms
> Header line off: 6900ms
> Faces default: 6100ms
> Header off and faces default: 5682ms
> 
> For comparison, header off and faces default with line numbers off: 3804ms
> 
> This does tell me I want to stop using inheritance in my theme, but it
> won't make as big of a difference w/ the hash patch I imagine.

Yes, which is why we want that patch, as soon as it's ready.

Re: macOS metal rendering engine in mac port

[Aaron Jensen]

On Sun, May 30, 2021 at 2:36 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Aaron Jensen <aaronjensen@gmail.com>
> > Date: Sun, 30 May 2021 00:04:43 -0700
> > Cc: Alan Third <alan@idiocy.org>, emacs-devel@gnu.org
> >
> > If I run the test on line 499 of xdisp.c I get:
> >
> > Native, hash, no line numbers: 3756ms
> > Native, hash, line numbers: 4185ms
> >
> > Native, alist, no line numbers: 4810ms
> > Native, alist, line numbers: 7173ms
>
> In an unoptimized build, "emacs -Q", without native-compilation, I get
> 26.39 and 27.22 sec, respectively.

My emacs -Q is 6s and 6.32s, respectively.

> > It's not my faces though, it's my header line that's causing that many
> > calls, possibly because it's triggering a redraw because the column
> > changed? I'm not sure how mode/header lines work when they update.
>
> You have the column displayed on your header-line?

Yes, I do, though maybe that's a bad idea. Does that cause a full
redisplay when typing rather than just updating the individual line?

Re: macOS metal rendering engine in mac port

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Sun, 30 May 2021 08:46:45 -0700
> Cc: Alan Third <alan@idiocy.org>, emacs-devel@gnu.org
> 
> On Sun, May 30, 2021 at 2:36 AM Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > > From: Aaron Jensen <aaronjensen@gmail.com>
> > > Date: Sun, 30 May 2021 00:04:43 -0700
> > > Cc: Alan Third <alan@idiocy.org>, emacs-devel@gnu.org
> > >
> > > If I run the test on line 499 of xdisp.c I get:
> > >
> > > Native, hash, no line numbers: 3756ms
> > > Native, hash, line numbers: 4185ms
> > >
> > > Native, alist, no line numbers: 4810ms
> > > Native, alist, line numbers: 7173ms
> >
> > In an unoptimized build, "emacs -Q", without native-compilation, I get
> > 26.39 and 27.22 sec, respectively.
> 
> My emacs -Q is 6s and 6.32s, respectively.

A similar (and minor) slowdown, in relative terms.

> > > It's not my faces though, it's my header line that's causing that many
> > > calls, possibly because it's triggering a redraw because the column
> > > changed? I'm not sure how mode/header lines work when they update.
> >
> > You have the column displayed on your header-line?
> 
> Yes, I do, though maybe that's a bad idea. Does that cause a full
> redisplay when typing rather than just updating the individual line?

Not a full redisplay, but it does redisplay the header line in
addition to the point's line, and displaying the header line most
probably needs more face-merging.

Re: macOS metal rendering engine in mac port

[Aaron Jensen]

On Sun, May 30, 2021 at 9:03 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Aaron Jensen <aaronjensen@gmail.com>
> > Date: Sun, 30 May 2021 08:46:45 -0700
> > Cc: Alan Third <alan@idiocy.org>, emacs-devel@gnu.org
> >
> > On Sun, May 30, 2021 at 2:36 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > >
> > > > From: Aaron Jensen <aaronjensen@gmail.com>
> > > > Date: Sun, 30 May 2021 00:04:43 -0700
> > > > Cc: Alan Third <alan@idiocy.org>, emacs-devel@gnu.org
> > > >
> > > > If I run the test on line 499 of xdisp.c I get:
> > > >
> > > > Native, hash, no line numbers: 3756ms
> > > > Native, hash, line numbers: 4185ms
> > > >
> > > > Native, alist, no line numbers: 4810ms
> > > > Native, alist, line numbers: 7173ms
> > >
> > > In an unoptimized build, "emacs -Q", without native-compilation, I get
> > > 26.39 and 27.22 sec, respectively.
> >
> > My emacs -Q is 6s and 6.32s, respectively.
>
> A similar (and minor) slowdown, in relative terms.

Yes, which, just for my own edification, we can attribute to fewer
faces in the alist ahead of the line number faces, right? Which is
mitigated by the hash patch. I just want to make sure we're not still
trying to chase something down.

> > > > It's not my faces though, it's my header line that's causing that many
> > > > calls, possibly because it's triggering a redraw because the column
> > > > changed? I'm not sure how mode/header lines work when they update.
> > >
> > > You have the column displayed on your header-line?
> >
> > Yes, I do, though maybe that's a bad idea. Does that cause a full
> > redisplay when typing rather than just updating the individual line?
>
> Not a full redisplay, but it does redisplay the header line in
> addition to the point's line, and displaying the header line most
> probably needs more face-merging.

When displaying column number and moving my point to the left, I get
about 1300 face lookups. When not displaying column number, I get 30.
This is with my config, with line numbers on.

Re: macOS metal rendering engine in mac port

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Sun, 30 May 2021 09:16:53 -0700
> Cc: Alan Third <alan@idiocy.org>, emacs-devel@gnu.org
> 
> > > > In an unoptimized build, "emacs -Q", without native-compilation, I get
> > > > 26.39 and 27.22 sec, respectively.
> > >
> > > My emacs -Q is 6s and 6.32s, respectively.
> >
> > A similar (and minor) slowdown, in relative terms.
> 
> Yes, which, just for my own edification, we can attribute to fewer
> faces in the alist ahead of the line number faces, right?

Yes, I think so.

> > Not a full redisplay, but it does redisplay the header line in
> > addition to the point's line, and displaying the header line most
> > probably needs more face-merging.
> 
> When displaying column number and moving my point to the left, I get
> about 1300 face lookups. When not displaying column number, I get 30.
> This is with my config, with line numbers on.

Look at the faces for which lface_from_face_name_no_resolve is called,
and see what that tells you.

  (gdb) break lface_from_face_name_no_resolve
  (gdb) commands
  > pp face_name
  > continue
  > end

Re: macOS metal rendering engine in mac port

[Aaron Jensen]

On Sun, May 30, 2021 at 9:35 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > When displaying column number and moving my point to the left, I get
> > about 1300 face lookups. When not displaying column number, I get 30.
> > This is with my config, with line numbers on.
>
> Look at the faces for which lface_from_face_name_no_resolve is called,
> and see what that tells you.
>
>   (gdb) break lface_from_face_name_no_resolve
>   (gdb) commands
>   > pp face_name
>   > continue
>   > end

This is a sampling of some of the faces and their counts. It's only
about 300 of the 1300, I'm having tmux copy/paste trouble:

  41 default
   6 font-lock-builtin-face
   4 font-lock-comment-delimiter-face
   7 font-lock-comment-face
   1 font-lock-function-name-face
   6 font-lock-preprocessor-face
  12 font-lock-string-face
   1 font-lock-variable-name-face
   1 header-line
  41 line-number
  20 line-number-current-line
  48 nano-face-faded
  21 nano-face-header-ancillary
  13 nano-face-header-default
   5 nano-face-header-faded
  12 nano-face-header-strong
  12 nano-face-popout
   6 nano-face-salient
  14 nano-face-strong
  41 shadow



When emacs is idle, it seems to spam face lookups continuously. Here's
a sample of that:

  48 default
   5 font-lock-builtin-face
   6 font-lock-comment-delimiter-face
  10 font-lock-comment-face
   1 font-lock-constant-face
   3 font-lock-function-name-face
   1 font-lock-negation-char-face
   5 font-lock-preprocessor-face
   5 font-lock-string-face
   3 font-lock-variable-name-face
   1 header-line
  48 line-number
  24 line-number-current-line
  59 nano-face-faded
  21 nano-face-header-ancillary
  13 nano-face-header-default
   5 nano-face-header-faded
  12 nano-face-header-strong
   5 nano-face-popout
   6 nano-face-salient
  18 nano-face-strong
  48 shadow

Re: macOS metal rendering engine in mac port

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Sun, 30 May 2021 10:00:00 -0700
> Cc: Alan Third <alan@idiocy.org>, emacs-devel@gnu.org
> 
> >   (gdb) break lface_from_face_name_no_resolve
> >   (gdb) commands
> >   > pp face_name
> >   > continue
> >   > end
> 
> This is a sampling of some of the faces and their counts. It's only
> about 300 of the 1300, I'm having tmux copy/paste trouble:
> 
>   41 default
>    6 font-lock-builtin-face
>    4 font-lock-comment-delimiter-face
>    7 font-lock-comment-face
>    1 font-lock-function-name-face
>    6 font-lock-preprocessor-face
>   12 font-lock-string-face
>    1 font-lock-variable-name-face

These are expected: they are faces used by buffer text.

>    1 header-line

Also expected.

>   41 line-number
>   20 line-number-current-line

Expected when line numbers are displayed.

>   48 nano-face-faded
>   21 nano-face-header-ancillary
>   13 nano-face-header-default
>    5 nano-face-header-faded
>   12 nano-face-header-strong
>   12 nano-face-popout
>    6 nano-face-salient
>   14 nano-face-strong

These are most probably due to massive inheritance in the nano theme.

>   41 shadow

This is because line-number and line-number-current-line inherit from
shadow.

> When emacs is idle, it seems to spam face lookups continuously. Here's
> a sample of that:

Is this "emacs -Q"?  If so, does it help to disable blink-cursor-mode
and global-eldoc-mode?

FWIW, I don't see any "spamming" like you do.  If the above 2 minor
modes don't explain that, I would be interested to see backtraces from
some of these lookups.

Re: macOS metal rendering engine in mac port

[Aaron Jensen]

On Sun, May 30, 2021 at 10:18 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > When emacs is idle, it seems to spam face lookups continuously. Here's
> > a sample of that:
>
> Is this "emacs -Q"?  If so, does it help to disable blink-cursor-mode
> and global-eldoc-mode?

It's not in emacs -Q, it was my config. It's intermittent. I can't
reproduce it right now. If I see it again I'll try and grab a profile,
but I'm not too worried about it at the moment.

Do you think I should bother getting rid of the inheritance in my
theme? Will it cause any issues to have that much inheritance once the
hash patch is merged?

Re: macOS metal rendering engine in mac port

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Sun, 30 May 2021 16:59:15 -0700
> Cc: Alan Third <alan@idiocy.org>, emacs-devel@gnu.org
> 
> On Sun, May 30, 2021 at 10:18 AM Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > > When emacs is idle, it seems to spam face lookups continuously. Here's
> > > a sample of that:
> >
> > Is this "emacs -Q"?  If so, does it help to disable blink-cursor-mode
> > and global-eldoc-mode?
> 
> It's not in emacs -Q, it was my config. It's intermittent. I can't
> reproduce it right now. If I see it again I'll try and grab a profile,
> but I'm not too worried about it at the moment.

Profile will not necessarily explain what's going on.  That's why I
asked for backtraces.

> Do you think I should bother getting rid of the inheritance in my
> theme?

Massive face inheritance makes face merging slower.

> Will it cause any issues to have that much inheritance once the hash
> patch is merged?

The effect should be much less prominent after that patch is
installed.

Re: macOS metal rendering engine in mac port

[Aaron Jensen]

On Sun, May 30, 2021 at 7:28 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > It's not in emacs -Q, it was my config. It's intermittent. I can't
> > reproduce it right now. If I see it again I'll try and grab a profile,
> > but I'm not too worried about it at the moment.
>
> Profile will not necessarily explain what's going on.  That's why I
> asked for backtraces.

Got it. I'll keep that in mind if I see it again. Thank you for your
assistance with this.

Best,

Aaron

Re: macOS metal rendering engine in mac port

[Alan Third]

On Sun, May 30, 2021 at 07:30:18PM -0700, Aaron Jensen wrote:
> On Sun, May 30, 2021 at 7:28 PM Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > > It's not in emacs -Q, it was my config. It's intermittent. I can't
> > > reproduce it right now. If I see it again I'll try and grab a profile,
> > > but I'm not too worried about it at the moment.
> >
> > Profile will not necessarily explain what's going on.  That's why I
> > asked for backtraces.
> 
> Got it. I'll keep that in mind if I see it again. Thank you for your
> assistance with this.

FYI I've pushed the relevant bits of the surface-stuff branch to
master as 246e107d73.
-- 
Alan Third

Re: macOS metal rendering engine in mac port

[Aaron Jensen]

On Thu, Jun 3, 2021 at 2:42 PM Alan Third <alan@idiocy.org> wrote:
>
> On Sun, May 30, 2021 at 07:30:18PM -0700, Aaron Jensen wrote:
> > On Sun, May 30, 2021 at 7:28 PM Eli Zaretskii <eliz@gnu.org> wrote:
> > >
> > > > It's not in emacs -Q, it was my config. It's intermittent. I can't
> > > > reproduce it right now. If I see it again I'll try and grab a profile,
> > > > but I'm not too worried about it at the moment.
> > >
> > > Profile will not necessarily explain what's going on.  That's why I
> > > asked for backtraces.
> >
> > Got it. I'll keep that in mind if I see it again. Thank you for your
> > assistance with this.
>
> FYI I've pushed the relevant bits of the surface-stuff branch to
> master as 246e107d73.

I saw that, thank you. I've experienced a couple of segfaults
recently, but I'm now on the latest master and haven't seen any. I'll
open a new bug if they're still happening.

With this and the hash patch, Emacs feels faster for me than it ever
has with my config. Thank you all!

Re: macOS metal rendering engine in mac port

[Aaron Jensen]

On Thu, Jun 3, 2021 at 5:42 PM Alan Third <alan@idiocy.org> wrote:
>
> FYI I've pushed the relevant bits of the surface-stuff branch to
> master as 246e107d73.

Hi Alan,

It's infrequent, but I've seen a number of rendering artifacts in 28
in the last month or so. Typically it is a line of group of lines that
are painted twice (i.e. in the wrong place). I may see line 33
duplicated so there is no 34, just two 33 in a row. Scrolling to
change the position does not fix it. I have to scroll the buggy line
out of view entirely and scroll it back to get it to be right.

I do not have a repro for this unfortunately.

Re: macOS metal rendering engine in mac port

[Illia Ostapyshyn]

Aaron Jensen <aaronjensen@gmail.com> writes:
> It's infrequent, but I've seen a number of rendering artifacts in 28
> in the last month or so. Typically it is a line of group of lines that
> are painted twice (i.e. in the wrong place). I may see line 33
> duplicated so there is no 34, just two 33 in a row. Scrolling to
> change the position does not fix it. I have to scroll the buggy line
> out of view entirely and scroll it back to get it to be right.
>
> I do not have a repro for this unfortunately.

I can confirm that I have been having this exact issue for quite some
time now. It is very infrequent and mild so I never bothered to report
it.

I also don't have any ideas what's causing it and how to reproduce it,
but M-x redraw-display RET fixes it straight away.

Re: macOS metal rendering engine in mac port

[Alan Third]

On Wed, Sep 15, 2021 at 09:30:09PM +0200, Illia Ostapyshyn wrote:
> Aaron Jensen <aaronjensen@gmail.com> writes:
> > It's infrequent, but I've seen a number of rendering artifacts in 28
> > in the last month or so. Typically it is a line of group of lines that
> > are painted twice (i.e. in the wrong place). I may see line 33
> > duplicated so there is no 34, just two 33 in a row. Scrolling to
> > change the position does not fix it. I have to scroll the buggy line
> > out of view entirely and scroll it back to get it to be right.
> >
> > I do not have a repro for this unfortunately.
> 
> I can confirm that I have been having this exact issue for quite some
> time now. It is very infrequent and mild so I never bothered to report
> it.
> 
> I also don't have any ideas what's causing it and how to reproduce it,
> but M-x redraw-display RET fixes it straight away.

If either of you do manage to come up with a recipe for reproducing
it, please let me know.

The most obvious candidate for incorrect duplication is in the
scrolling code. But since it's correct all the rest of the time there
would have to be something else forcing it.

Unless I just completely messed up the code in copyRect and it
sometimes copies lines of pixels in the wrong order, that can do
exactly what you're describing... But it works correctly practically
all the time, so it would have to be a rare edge case. 🤔
-- 
Alan Third

Re: macOS metal rendering engine in mac port

[Y. E. via Emacs development discussions.]

>> > It's infrequent, but I've seen a number of rendering artifacts in 28
>> > in the last month or so. Typically it is a line of group of lines that
>> > are painted twice (i.e. in the wrong place). I may see line 33
>> > duplicated so there is no 34, just two 33 in a row. Scrolling to
>> > change the position does not fix it. I have to scroll the buggy line
>> > out of view entirely and scroll it back to get it to be right.
>> >
>> > I do not have a repro for this unfortunately.
>>
>> I can confirm that I have been having this exact issue for quite some
>> time now. It is very infrequent and mild so I never bothered to report
>> it.
>>
>> I also don't have any ideas what's causing it and how to reproduce it,
>> but M-x redraw-display RET fixes it straight away.

I saw this (or extremely similar) issue 2-3 times during the past month
on an oldish MacOS with vanilla Emacs, in buffers with ELisp code.

I looked as if chunk of the text (from this buffer) overlayed
another (correct) text. And it was impossible to remove that overlaying
text without reverting (AFAIR) the buffer.

Unfortunately, I also have no idea on how to reproduce the issue so far.

Re: macOS metal rendering engine in mac port

[Alan Third]

On Thu, Sep 16, 2021 at 06:59:33PM +0300, Y. E. wrote:
> 
> >> > It's infrequent, but I've seen a number of rendering artifacts in 28
> >> > in the last month or so. Typically it is a line of group of lines that
> >> > are painted twice (i.e. in the wrong place). I may see line 33
> >> > duplicated so there is no 34, just two 33 in a row. Scrolling to
> >> > change the position does not fix it. I have to scroll the buggy line
> >> > out of view entirely and scroll it back to get it to be right.
> >> >
> >> > I do not have a repro for this unfortunately.
> >>
> >> I can confirm that I have been having this exact issue for quite some
> >> time now. It is very infrequent and mild so I never bothered to report
> >> it.
> >>
> >> I also don't have any ideas what's causing it and how to reproduce it,
> >> but M-x redraw-display RET fixes it straight away.
> 
> I saw this (or extremely similar) issue 2-3 times during the past month
> on an oldish MacOS with vanilla Emacs, in buffers with ELisp code.
> 
> I looked as if chunk of the text (from this buffer) overlayed
> another (correct) text. And it was impossible to remove that overlaying
> text without reverting (AFAIR) the buffer.
> 
> Unfortunately, I also have no idea on how to reproduce the issue so far.

Nobody has any idea what they were doing when it happened? Scrolling
or typing or resizing windows or anything?

Someone in an unrelated bug report suggested something similar
happened after they created a new frame (which doesn't make much
sense, unless Emacs is drawing to the wrong frame). Was anyone doing
anything like that? Child frames popping up for use with, I don't
know, company mode or something?

Where on the frame do these things happen? If it happens again please
send a screenshot of the whole frame.
-- 
Alan Third

Re: macOS metal rendering engine in mac port

[Aaron Jensen]

On Fri, Sep 17, 2021 at 1:31 PM Alan Third <alan@idiocy.org> wrote:
> Nobody has any idea what they were doing when it happened? Scrolling
> or typing or resizing windows or anything?
>
> Someone in an unrelated bug report suggested something similar
> happened after they created a new frame (which doesn't make much
> sense, unless Emacs is drawing to the wrong frame). Was anyone doing
> anything like that? Child frames popping up for use with, I don't
> know, company mode or something?

I use company w/ child frames, so this is possible. It is an off by
one error in line rendering. It's not that it's lines from another
frame, they are from the same frame, just the line above typically.

> Where on the frame do these things happen? If it happens again please
> send a screenshot of the whole frame.

It happens only on a window at a time. Often in my left window around
the middle of the frame, maybe? I will try and capture a screenshot
next time.

Aaron

Re: macOS metal rendering engine in mac port

[Y. E. via Emacs development discussions.]

> Nobody has any idea what they were doing when it happened? Scrolling
> or typing or resizing windows or anything?

AFAIR, I switched from another buffer.

> Someone in an unrelated bug report suggested something similar
> happened after they created a new frame (which doesn't make much
> sense, unless Emacs is drawing to the wrong frame). Was anyone doing
> anything like that? Child frames popping up for use with, I don't
> know, company mode or something?

During the period I saw the artifacts I extensively used both additional
frames (but the artifacts were in the initial frame) and company-mode
with native tooltip overlay.

> Where on the frame do these things happen?

Middle part.

> If it happens again please send a screenshot of the whole frame.

Sure.

Re: macOS metal rendering engine in mac port

[Illia Ostapyshyn]

[-- Attachment #1: Type: text/plain, Size: 997 bytes --]


> On Sep 17, 2021, at 19:31, Alan Third <alan@idiocy.org> wrote:
> 
> Nobody has any idea what they were doing when it happened? Scrolling
> or typing or resizing windows or anything?
> 
> Someone in an unrelated bug report suggested something similar
> happened after they created a new frame (which doesn't make much
> sense, unless Emacs is drawing to the wrong frame). Was anyone doing
> anything like that? Child frames popping up for use with, I don't
> know, company mode or something?
> 
> Where on the frame do these things happen? If it happens again please
> send a screenshot of the whole frame.
> -- 
> Alan Third

I just had this happen to me as well, screenshots attached. I wasn’t switching buffers, just scrolling with the mouse wheel. The visible frame is the only frame (it’s in fullscreen) and there were no other frames since I started emacs.

I tried scrolling some of the bugged “as” out of the view and scrolling back, they were still there.


[-- Attachment #2.1: Type: text/html, Size: 1783 bytes --]

[-- Attachment #2.2: Screen Shot 2021-09-20 at 22.41.24.png --]
[-- Type: image/png, Size: 437811 bytes --]

[-- Attachment #2.3: Screen Shot 2021-09-20 at 22.41.41.png --]
[-- Type: image/png, Size: 418502 bytes --]

Re: macOS metal rendering engine in mac port

[Y. E. via Emacs development discussions.]

> I just had this happen to me as well, screenshots attached.

I confirm these screenshots correspond exactly to the issue I saw.
[I had no new cases so far.]

Re: macOS metal rendering engine in mac port

[Alan Third]

On Tue, Sep 21, 2021 at 10:22:38AM +0300, Y. E. wrote:
> 
> > I just had this happen to me as well, screenshots attached.
> 
> I confirm these screenshots correspond exactly to the issue I saw.
> [I had no new cases so far.]

Both of these look rather like copyRect is playing up but I can't see
what's wrong with it. There are only two callers of copyRect and I
can't see anything wrong with them either (and if it was THEIR callers
playing up we'd see similar problems outside of the NS port).

Aaron's actually looks like it could be copying FAR larger areas than
it's supposed to be (for example, wrapping off the right of the screen
and back on the left).

Illia's looks just like what happens when scrolling goes wrong. Bits
of lines end up on the wrong lines and then they get repeated as Emacs
copies bits of the frame around.

Maybe we just need to do something like this:

modified   src/nsterm.m
@@ -7882,6 +7882,7 @@ - (void)copyRect:(NSRect)srcRect to:(NSRect)dstRect
 #ifdef NS_IMPL_COCOA
   if ([self wantsLayer])
     {
+      ns_focus (emacsframe, nil, 0);
       double scale = [[self window] backingScaleFactor];
       CGContextRef context = [[NSGraphicsContext currentContext] CGContext];
       int bpp = CGBitmapContextGetBitsPerPixel (context) / 8;
@@ -7906,7 +7907,7 @@ - (void)copyRect:(NSRect)srcRect to:(NSRect)dstRect
           memmove ((char *) dstPixels + y * rowSize,
                    (char *) srcPixels + y * rowSize,
                    srcRowSize);
-
+      ns_unfocus (emacsframe);
     }
 #if MAC_OS_X_VERSION_MIN_REQUIRED < 101400
   else


It seems unlikely, though...
-- 
Alan Third

Re: macOS metal rendering engine in mac port

[Alan Third]

On Tue, Sep 21, 2021 at 07:48:50PM +0100, Alan Third wrote:
> On Tue, Sep 21, 2021 at 10:22:38AM +0300, Y. E. wrote:
> > 
> > > I just had this happen to me as well, screenshots attached.
> > 
> > I confirm these screenshots correspond exactly to the issue I saw.
> > [I had no new cases so far.]
> 
> Both of these look rather like copyRect is playing up but I can't see
> what's wrong with it. There are only two callers of copyRect and I
> can't see anything wrong with them either (and if it was THEIR callers
> playing up we'd see similar problems outside of the NS port).
> 
> Aaron's actually looks like it could be copying FAR larger areas than
> it's supposed to be (for example, wrapping off the right of the screen
> and back on the left).
> 
> Illia's looks just like what happens when scrolling goes wrong. Bits
> of lines end up on the wrong lines and then they get repeated as Emacs
> copies bits of the frame around.

I've pushed a small change to master that *may* fix this, although I
doubt it, and adds a pile of logging if it detects the situation that
I suspect is causing this.

If you run from the terminal it will print the logging to it,
otherwise it'll appear in the system log, so if you see the glitch
please check the logs to see if there's anything in there.

Thanks!
-- 
Alan Third

Re: macOS metal rendering engine in mac port

[Aaron Jensen]

On Mon, Sep 27, 2021 at 6:08 AM Alan Third <alan@idiocy.org> wrote:
>
> I've pushed a small change to master that *may* fix this, although I
> doubt it, and adds a pile of logging if it detects the situation that
> I suspect is causing this.
>
> If you run from the terminal it will print the logging to it,
> otherwise it'll appear in the system log, so if you see the glitch
> please check the logs to see if there's anything in there.


Not definitive, but I have not seen this happen since building with
this potential fix. I'll let you know and include logs/screenshot if I
see it again.

Thanks,

Aaron

Re: macOS metal rendering engine in mac port

[Illia Ostapyshyn]

[-- Attachment #1: Type: text/plain, Size: 1423 bytes --]

> On Sep 27, 2021, at 12:07, Alan Third <alan@idiocy.org> wrote:
> 
> I've pushed a small change to master that *may* fix this, although I
> doubt it, and adds a pile of logging if it detects the situation that
> I suspect is causing this.
> 
> If you run from the terminal it will print the logging to it,
> otherwise it'll appear in the system log, so if you see the glitch
> please check the logs to see if there's anything in there.
> 
> Thanks!
> -- 
> Alan Third

The glitch just happened again after a long time. I’m not sure whether
the logging is still in code, but I couldn’t find any relevant messages
in the system log (http://sprunge.us/heJzLM) except for this line:

  Oct 25 21:16:30 mbp-2018 com.apple.xpc.launchd[1]: Coalition Cache Hit: app<application.org.gnu.Emacs.12664035.12664040(501)> [1660]

Screenshot attached. I just switched from another buffer as it happened.

In GNU Emacs 28.0.60 (build 2, x86_64-apple-darwin20.6.0, NS appkit-2022.60 Version 11.6 (Build 20G165))
 of 2021-10-20 built on mbp-2018.local
Repository revision: 4540130312b8e9dbbe930ba2ffb32e5e51560514
Repository branch: emacs-28
Windowing system distributor 'Apple', version 10.3.2022
System Description:  macOS 11.6

Configured using:
 'configure --with-native-compilation --disable-ns-self-contained
 --prefix=/Users/iostapyshyn/.local 'CFLAGS=-O2 -march=native
 -fomit-frame-pointer''


[-- Attachment #2.1: Type: text/html, Size: 2439 bytes --]

[-- Attachment #2.2: Screen Shot 2021-10-25 at 21.16.47.png --]
[-- Type: image/png, Size: 566190 bytes --]

Re: macOS metal rendering engine in mac port

[Alan Third]

On Mon, Oct 25, 2021 at 09:39:50PM +0200, Illia Ostapyshyn wrote:
> > On Sep 27, 2021, at 12:07, Alan Third <alan@idiocy.org> wrote:
> > 
> > I've pushed a small change to master that *may* fix this, although I
> > doubt it, and adds a pile of logging if it detects the situation that
> > I suspect is causing this.
> > 
> > If you run from the terminal it will print the logging to it,
> > otherwise it'll appear in the system log, so if you see the glitch
> > please check the logs to see if there's anything in there.
> > 
> > Thanks!
> 
> The glitch just happened again after a long time. I’m not sure whether
> the logging is still in code, but I couldn’t find any relevant messages
> in the system log (http://sprunge.us/heJzLM) except for this line:
> 
>   Oct 25 21:16:30 mbp-2018 com.apple.xpc.launchd[1]: Coalition Cache Hit: app<application.org.gnu.Emacs.12664035.12664040(501)> [1660]
> 
> Screenshot attached. I just switched from another buffer as it happened.

I think it would say "org.gnu.Emacs" instead of
"com.apple.xpc.launchd" if it was Emacs logging. Thanks for looking.

I'm pretty stumped with this. I actually suspect there were two bugs
and I've probably fixed one, but the other is still there.
-- 
Alan Third

Re: macOS metal rendering engine in mac port

[Aaron Jensen]

On Tue, Oct 26, 2021 at 8:16 AM Alan Third <alan@idiocy.org> wrote:
>
> On Mon, Oct 25, 2021 at 09:39:50PM +0200, Illia Ostapyshyn wrote:
> > > On Sep 27, 2021, at 12:07, Alan Third <alan@idiocy.org> wrote:
> > >
> > > I've pushed a small change to master that *may* fix this, although I
> > > doubt it, and adds a pile of logging if it detects the situation that
> > > I suspect is causing this.
> > >
> > > If you run from the terminal it will print the logging to it,
> > > otherwise it'll appear in the system log, so if you see the glitch
> > > please check the logs to see if there's anything in there.
> > >
> > > Thanks!
> >
> > The glitch just happened again after a long time. I’m not sure whether
> > the logging is still in code, but I couldn’t find any relevant messages
> > in the system log (http://sprunge.us/heJzLM) except for this line:
> >
> >   Oct 25 21:16:30 mbp-2018 com.apple.xpc.launchd[1]: Coalition Cache Hit: app<application.org.gnu.Emacs.12664035.12664040(501)> [1660]
> >
> > Screenshot attached. I just switched from another buffer as it happened.
>
> I think it would say "org.gnu.Emacs" instead of
> "com.apple.xpc.launchd" if it was Emacs logging. Thanks for looking.
>
> I'm pretty stumped with this. I actually suspect there were two bugs
> and I've probably fixed one, but the other is still there.

I've not seen the full line problem that I had sent a screenshot of
before, so that may be fixed. I *have* seen at least twice now a spot
on a window that was painted w/ the background color and none of the
glyphs it should have had. I didn't really know what was going on so I
forgot to get a screenshot, but I will try to next time.

Thanks,

Aaron

Re: macOS metal rendering engine in mac port

[Rudolf Adamkovič]

Aaron Jensen <aaronjensen@gmail.com> writes:

> On Thu, Jun 3, 2021 at 5:42 PM Alan Third <alan@idiocy.org> 
> wrote: 
>> 
>> FYI I've pushed the relevant bits of the surface-stuff branch 
>> to master as 246e107d73. 
> 
> Hi Alan, 
> 
> It's infrequent, but I've seen a number of rendering artifacts 
> in 28 in the last month or so. Typically it is a line of group 
> of lines […] 

+1 I see these rendering bugs about once a week.

R+ 

-- 
"Contrariwise," continued Tweedledee, "if it was so, it might be; 
and if it were so, it would be; but as it isn't, it ain't. That's 
logic." -- Lewis Carroll, Through the Looking Glass  Rudolf 
Adamkovič <salutis@me.com> Studenohorská 25 84103 Bratislava 
Slovakia  [he/him]

Re: macOS metal rendering engine in mac port

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Sat, 29 May 2021 14:03:08 -0700
> Cc: Alan Third <alan@idiocy.org>, emacs-devel@gnu.org
> 
> > Also, please note that typing a single character redisplays just one
> > line, the one where point is.  That perhaps needs to merge 4 or 5
> > faces.  So I'm not sure how come this could add 10ms to every
> > keypress: you'd need 20,000 calls of assq_no_quit to account for 10ms.
> > How come we call assq_no_quit 20k times when processing insertion of a
> > single character?
> 
> So with a single keypress I see:
> 
> 6,000 lface_from_face_name_no_resolve
> 19,000 assq_no_quit

In "emacs -Q" I get only about 180 calls to
lface_from_face_name_no_resolve when I type a single character,
depending on where in xdisp.c I do that.  How many calls do you see
when you just move the cursor to the left or to the right one
character position?

> > > > I see a lot of :inherit there.  I'm quite sure this exacerbates the
> > > > problem, as each :inherit needs to recursively search for and access
> > > > the attributes of the parent face.
> > >
> > > It only navigates the parent when the face matches, yes?
> >
> > Which face matches what?
> >
> > Emacs needs to access the parent face each time it merges the
> > inheriting face with another one, because it needs to resolve all the
> > attributes of each face it merges.
> 
> Sorry, I mean having 900 new faces with inherits shouldn't change the
> time it takes to merge faces for a single face. In other words,
> inherit only adds instructions when the face being merged has
> inherits. It doesn't add it when 900 not-being-merged faces have
> inherits.

But in your case, it looks like every face inherits.  So each time
Emacs finds the face it needs to merge by looking in frame's face
alist, it then needs to look again to find the parent of that face.

Re: macOS metal rendering engine in mac port

[Alan Third]

On Sat, May 29, 2021 at 01:52:35AM -0700, Aaron Jensen wrote:
> 
> emacs -Q never really felt slow in terms of typing latency. In terms
> of the scroll benchmark, I got:
> 
> w/o patch: 26.8s first run, 3.84s second run
> w/ patch: 25.1s first run, 3.6s second run
> 
> With my emacs config that has, with everything loaded, 1156 faces, I get:
> 
> w/o patch: 18.6s on second run (at least 9s of which are attributed to
> TAGGEDP and CONSP from lface_from_face_name_no_resolve)
> w/ patch: 6.1s on second run
> 
> The impact is drastic.

It makes me wonder if we're doing something very silly with faces in
the NS port, but after a quick look through I don't see anything
obvious. I don't really know what I'd be looking for though.

One thing I know that's odd in the NS port is that we work out which
face we need on the fly, whereas the other terms seem to have a
central function that works out the faces early. But I don't believe
that should have any effect as it all appears to be fairly simple
lookups.
-- 
Alan Third

Re: macOS metal rendering engine in mac port

[Eli Zaretskii]

> Date: Sat, 29 May 2021 10:12:26 +0100
> From: Alan Third <alan@idiocy.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> 
> One thing I know that's odd in the NS port is that we work out which
> face we need on the fly, whereas the other terms seem to have a
> central function that works out the faces early.

What do you mean by "which face" (singular)?  Redisplay of a typical
buffer under a major mode such as CC Mode usually needs to use and
merge about a dozen of different faces (think font-lock), so there
isn't a single face to figure it out.  Maybe you mean the default
face?  That one gets computed whenever we start the display operation,
such as redisplaying a window, and is reused until we are done with
the window.  Then we compute it again when (or if) we go to redisplay
another window.

Re: macOS metal rendering engine in mac port

[Alan Third]

On Sat, May 29, 2021 at 12:26:10PM +0300, Eli Zaretskii wrote:
> > Date: Sat, 29 May 2021 10:12:26 +0100
> > From: Alan Third <alan@idiocy.org>
> > Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> > 
> > One thing I know that's odd in the NS port is that we work out which
> > face we need on the fly, whereas the other terms seem to have a
> > central function that works out the faces early.
> 
> What do you mean by "which face" (singular)?  Redisplay of a typical
> buffer under a major mode such as CC Mode usually needs to use and
> merge about a dozen of different faces (think font-lock), so there
> isn't a single face to figure it out.  Maybe you mean the default
> face?  That one gets computed whenever we start the display operation,
> such as redisplaying a window, and is reused until we are done with
> the window.  Then we compute it again when (or if) we go to redisplay
> another window.

Yes, I think that's what I'm talking about. There's a lot of code like this:

  struct face *face = FRAME_DEFAULT_FACE (f);
  [ns_lookup_indexed_color (NS_FACE_BACKGROUND (face), f) set];

and

  if (s->hl == DRAW_MOUSE_FACE)
    {
      face = FACE_FROM_ID_OR_NULL (s->f,
				   MOUSE_HL_INFO (s->f)->mouse_face_face_id);
      if (!face)
        face = FACE_FROM_ID (s->f, MOUSE_FACE_ID);
    }
  else
    face = s->face;

Which I don't think is present in the other terms, because, as I say,
they look them up in one function rather than spread out throughout
the term's code.

But again, I don't think this should recalculate anything. Macros like
FACE_FROM_ID_OR_NULL appear to be doing simple lookups that shouldn't
slow anything down, unless I'm missing something.
-- 
Alan Third

Re: macOS metal rendering engine in mac port

[Eli Zaretskii]

> Date: Sat, 29 May 2021 10:32:00 +0100
> From: Alan Third <alan@idiocy.org>
> Cc: aaronjensen@gmail.com, emacs-devel@gnu.org
> 
> Yes, I think that's what I'm talking about. There's a lot of code like this:
> 
>   struct face *face = FRAME_DEFAULT_FACE (f);
>   [ns_lookup_indexed_color (NS_FACE_BACKGROUND (face), f) set];
> 
> and
> 
>   if (s->hl == DRAW_MOUSE_FACE)
>     {
>       face = FACE_FROM_ID_OR_NULL (s->f,
> 				   MOUSE_HL_INFO (s->f)->mouse_face_face_id);
>       if (!face)
>         face = FACE_FROM_ID (s->f, MOUSE_FACE_ID);
>     }
>   else
>     face = s->face;
> 
> Which I don't think is present in the other terms, because, as I say,
> they look them up in one function rather than spread out throughout
> the term's code.

I cannot see why this would be a problem.  First, FACE_FROM_ID and
FACE_FROM_ID_OR_NULL simply access a face by direct indexing into the
frame's face cache, so it's just a couple of CPU instructions.  And
second, I see very similar code in other *term.c sources, so I don't
think nsterm.m does it very differently.

> But again, I don't think this should recalculate anything. Macros like
> FACE_FROM_ID_OR_NULL appear to be doing simple lookups that shouldn't
> slow anything down, unless I'm missing something.

Exactly.

Re: macOS metal rendering engine in mac port

[Eli Zaretskii]

> Date: Sat, 29 May 2021 12:37:00 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: aaronjensen@gmail.com, emacs-devel@gnu.org
> 
> > Date: Sat, 29 May 2021 10:32:00 +0100
> > From: Alan Third <alan@idiocy.org>
> > Cc: aaronjensen@gmail.com, emacs-devel@gnu.org
> > 
> > Yes, I think that's what I'm talking about. There's a lot of code like this:
> > 
> >   struct face *face = FRAME_DEFAULT_FACE (f);
> >   [ns_lookup_indexed_color (NS_FACE_BACKGROUND (face), f) set];
> > 
> > and
> > 
> >   if (s->hl == DRAW_MOUSE_FACE)
> >     {
> >       face = FACE_FROM_ID_OR_NULL (s->f,
> > 				   MOUSE_HL_INFO (s->f)->mouse_face_face_id);
> >       if (!face)
> >         face = FACE_FROM_ID (s->f, MOUSE_FACE_ID);
> >     }
> >   else
> >     face = s->face;
> > 
> > Which I don't think is present in the other terms, because, as I say,
> > they look them up in one function rather than spread out throughout
> > the term's code.
> 
> I cannot see why this would be a problem.  First, FACE_FROM_ID and
> FACE_FROM_ID_OR_NULL simply access a face by direct indexing into the
> frame's face cache, so it's just a couple of CPU instructions.  And
> second, I see very similar code in other *term.c sources, so I don't
> think nsterm.m does it very differently.

Of course, what I say above doesn't include ns_lookup_indexed_color,
so maybe that could explain some slowness?

Re: macOS metal rendering engine in mac port

[Alan Third]

On Sat, May 29, 2021 at 12:39:27PM +0300, Eli Zaretskii wrote:
> > Date: Sat, 29 May 2021 12:37:00 +0300
> > From: Eli Zaretskii <eliz@gnu.org>
> > Cc: aaronjensen@gmail.com, emacs-devel@gnu.org
> > 
> > I cannot see why this would be a problem.  First, FACE_FROM_ID and
> > FACE_FROM_ID_OR_NULL simply access a face by direct indexing into the
> > frame's face cache, so it's just a couple of CPU instructions.  And
> > second, I see very similar code in other *term.c sources, so I don't
> > think nsterm.m does it very differently.
> 
> Of course, what I say above doesn't include ns_lookup_indexed_color,
> so maybe that could explain some slowness?

No, it looks like a simple lookup into an array too.
-- 
Alan Third

Re: macOS metal rendering engine in mac port

[Alan Third]

On Sat, May 29, 2021 at 12:39:27PM +0300, Eli Zaretskii wrote:
> 
> Of course, what I say above doesn't include ns_lookup_indexed_color,
> so maybe that could explain some slowness?

It looks very simple too, so probably not.
-- 
Alan Third

Re: macOS metal rendering engine in mac port

[Tim Cross]

Alan Third <alan@idiocy.org> writes:

> I don't really care one way or the other, I'm already using my new
> ThinkPad as my daily driver and it would be quite nice to see the back
> of the people on Reddit telling me I'm actively harming the Free
> Software movement by maintaining the NS port instead of letting it die
> so everyone is forced to use the Mac port.
>

I for one have appreciated all the hard work maintaining the NS port.
Diversity in the macOS world is likely the only way Emacs will survive
on that platform, so I'm pleased we have both the NS and 'macport'
versions. Thank you for your contributions.

Reddit can be a toxic environment full of ill-informed opinion. The only
place I see more bad advice is stack overflow. I find my quality of life
without reddit is higher than with it!

-- 
Tim Cross