bug#73563: [Ben Simms] Performance bottleneck in ns_draw_fringe_bitmap

bug#73563: [Ben Simms] Performance bottleneck in ns_draw_fringe_bitmap

[Stefan Kangas]

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

I'm forwarding this to the bug tracker so that we don't lose track of
it.

Original message:
https://lists.gnu.org/r/emacs-devel/2024-06/msg00900.html

-------------------- Start of forwarded message --------------------
From: Ben Simms <ben@bensimms.moe>
Date: Wed, 26 Jun 2024 13:56:43 +0200
Subject: Performance bottleneck in ns_draw_fringe_bitmap
To: emacs-devel@gnu.org

[-- Attachment #2: Type: text/plain, Size: 67 bytes --]

-------------------- End of forwarded message --------------------

[-- Attachment #3: Type: text/html, Size: 23281 bytes --]

bug#73563: [Ben Simms] Performance bottleneck in ns_draw_fringe_bitmap

[Eli Zaretskii]

> Cc: Ben Simms <ben@bensimms.moe>
> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Mon, 30 Sep 2024 07:21:03 +0000
> 
> Hi all, I recently started using Emacs (ns) HEAD on an ARM macos sonoma
> system.
> 
> I've noticed that ns_draw_fringe_bitmap is a fairly large performance sink
> when using pixel scrolling (to the point of 99% of cpu time being inside this
> function, with Emacs drawing at approx 5Hz). The slowness here isn't as
> obvious when not pixel scrolling, presumably because Emacs never tries to
> redraw at 60+Hz otherwise.
> 
> I have performed some profiling and discovered that in my observed worse case
> situation, of the 99% of cpu time spent in ns_draw_fringe_bitmap, approx 50%
> is spent in [NSBezierPath copy], and approx 30% in [NSBezierPath fill].

According to the posted profile, ns_draw_fringe_bitmap takes much less
than 99% of CPU time, somewhere around 10%.  What am I missing?