bug#48734: 28.0.50; Performance regression in `string-width`?

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Imran Khan <contact@imrankhan.live>,  48734@debbugs.gnu.org
> Date: Sun, 30 May 2021 14:18:44 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > If deft-mode wants to allocate space on display, then they really do
> > need to use string-width, but then the changes which make them "hang"
> > are really important, because before that string-width would compute
> > the result incorrectly when characters are composed on display.
> 
> string-width has always been approximate (but fast), hasn't it?  And to
> determine the actual display width you've had to use
> window-text-pixel-size or the like.

That should still be the case, although string-width will now be a bit
slower when the string includes characters which need to be composed
on display.

> Perhaps string-width should get an extra parameter to get the new, more
> accurate computation, and get the old, fast computation without this
> parameter.

That's really easy with the last change I made: the option to do that
exists on the C level.  So if there are significant use cases where
people report slowdown, we could expose the option to Lisp.

FWIW, I did measure the speed after the change, and saw only something
like 10% slowdown for strings with composable characters.  Maybe my
tests were skewed, or maybe there are other use cases I didn't think
about.