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

Previous Next

Full log

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

From: Alan Third <alan <at> idiocy.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 ben <at> bensimms.moe, 73563 <at> debbugs.gnu.org,
 Jordan Ellis Coppard <jc+o.emacs <at> wz.ht>
Subject: Re: bug#73563: [Ben Simms] Performance bottleneck in
 ns_draw_fringe_bitmap
Date: Sat, 17 May 2025 12:23:53 +0100

On Sat, May 17, 2025 at 12:26:26PM +0300, Eli Zaretskii wrote:
> > Cc: Ben Simms <ben <at> bensimms.moe>
> > Date: Tue, 13 May 2025 20:37:55 +0900
> > From:  Jordan Ellis Coppard via "Bug reports for GNU Emacs,
> >  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> > 
> > Howdy,
> > 
> > 
> > I've been using the following patch (bottom of this email) until my most 
> > recent rebuild of Emacs from master. Since the recent commit fixing 
> > stipple drawing the patch can be reduced to just: 
> > https://github.com/emacs-mirror/emacs/commit/7f2efe6503fdce2a4e552c14802644a05b581bc7 
> > (link to a diff authored by Ben Simms).
> > 
> > I've now noticed again extreme slowdown when fringe bitmaps are used. It 
> > appears to be proportional to the number of bits set in the bitmap. An 
> > 'empty' bitmap (all zeroes) doesn't yield any noticeable slowdown, a 
> > bitmap with 1 bit set yields a little, with 2 its noticeable and with 
> > all 8 bits set Emacs takes up to 1 second to respond to any input at all.
> > 
> > This has been the case since at least August of last year. I can get a 
> > minimal reproduction but it has happened on completely different 
> > configurations with the only common denominator being the NS build (on 
> > ARM-based macOS), and the use of fringe bitmaps.
> > 
> > Below is trace with update_frame as the root context. Captured with 
> > Instruments.app (which uses dtrace and more under the hood IIRC).
> > 
> > ns_draw_fringe_bitmap takes up 94% of the time for the short 
> > reproduction this trace records. The deepest the trace goes is to 
> > CG::Path::recalculate_bounding_box() which eats 80% of time. So instead 
> > of a cached value the bounding box is being recalculated every time 
> > which appears very expensive, but beyond that I have close to zero 
> > experience with macOS' graphics stack.
> > 
> > I've just recompiled Emacs against the same commit of my recent master 
> > build (648453c04d9b91d96452b930c0c948b0b39b5dc0) except now with the 
> > patch applied (since the stipple changes are merged it's just the 
> > smallest subset: 
> > https://github.com/emacs-mirror/emacs/commit/7f2efe6503fdce2a4e552c14802644a05b581bc7) 
> > and once again fringe performance is back to being buttery smooth.
> 
> Alan and Gerd, any comments or suggestions?

I've not looked at it closely, but I will point out that AFAIK GNUStep
does not support Core Graphics, so any function or struct starting
with "CG" needs an alternative method in place.

-- 
Alan Third

Previous Next

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