GNU bug report logs - #73563
[Ben Simms] Performance bottleneck in ns_draw_fringe_bitmap

Previous Next

Package: emacs;

Reported by: Stefan Kangas <stefankangas <at> gmail.com>

Date: Mon, 30 Sep 2024 08:03:02 UTC

Severity: normal

Full log


Message #32 received at 73563 <at> debbugs.gnu.org (full text, mbox):

From: Jordan Ellis Coppard <jc+o.emacs <at> wz.ht>
To: Alan Third <alan <at> idiocy.org>, 73563 <at> debbugs.gnu.org,
 Ben Simms <ben <at> bensimms.moe>
Subject: Re: bug#73563: [Ben Simms] Performance bottleneck in
 ns_draw_fringe_bitmap
Date: Fri, 6 Jun 2025 19:01:45 +0900
On 4/6/2025 6:07 am, Alan Third wrote:
> Can you send a screenshot? That sounds odd.

I forgot to check that on emacs -Q and it appears to not be present 
there. In my config I change the size of the fringes a bit, however that 
might mean your patch doesn't account for that somehow. I'm still bisecting.

I've decided to record all 3 Emacs variants in-play here:

(1) Vanilla, unpatched Emacs.
(2) Emacs patched with Ben Simms' fringe changes.
(3) Emacs patched with yours (Alan Third's) fringe changes.

I've uploaded the three recordings to YouTube. All are emacs -Q. Note in 
1's case the extreme lag when scrolling the *test fringe bench* buffer 
and that in 2 and 3's case there is no such lag.

In all cases I start scrolling by holding down the arrow keys up/down 
(for simplicity, in actuality I am using C-n or a key set to run 
(next-line) and so forth) and then I scroll a bit with the trackpad.

I _think_ Ben's might be a bit more performant but at this point it 
feels like splitting hairs especially since there doesn't appear (yet) 
to be a concrete way to benchmark this without human interaction which 
is concerning (I think you and others would agree a way to get concrete 
data here would be better for long term regression testing).

Videos in respective order:
(1) https://www.youtube.com/watch?v=G8T0S1m-mLs
(2) https://www.youtube.com/watch?v=-9Ro3myXztM
(3) https://www.youtube.com/watch?v=CYwAfPBt8us

Here are four screenshots in the same respective order as the videos in 
terms of Emacs version. Unpatched Emacs with dape-mode shows no 
corruption, Ben's patch shows the frame and all it's windows borked 
(when it should look like 1, 3, or 4), your patch shows dape-mode 
without corruption, and the fourth screenshot which is Emacs (3) but 
with my dotfiles loaded shows the small 1-pixel-ish corruption in the 
margin (look at the fringe for lines 1-15). That corruption only appears 
when I scroll the buffer down and up. Whereas Ben's corruption appears 
immediately and indefinitely unless fringe-mode is toggled off.

Screenshots (direct links):
(1) https://i.imgur.com/BpXQxcj.png
(2) https://i.imgur.com/Nd3YPda.png
(3) https://i.imgur.com/gjPmMc2.png
(4) https://i.imgur.com/X2ybi2Q.png

Album link: https://imgur.com/a/0oReqr2

The window configurations in the Emacs frame (except for the fourth) are 
all exactly the same, screenshots taken at the same point in time:

M-x dape
M-x dape-breakpoint-toggle
and then 'r' in the dape console to start debugging.

I forgot to disable macOS' shadow-adding behaviour when capturing the 
screenshot.

Also there's a tangential thing I noticed. My benchmark takes ~18 
seconds to run under emacs -Q but (for all 3 Emacsen) only ~2.7 seconds 
when using my config 
(https://github.com/tsujp/dotfiles/tree/master/.config/emacs). As you 
can see from the fourth screenshot I disable native scroll bars, toolbar 
mode and various other things. Such a huge increase in performance there 
is.. perhaps concerning too.


/Jordan




This bug report was last modified 14 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.