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

[Eli Zaretskii]

> Date: Mon, 31 May 2021 21:51:13 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 48734@debbugs.gnu.org
> 
> > Date: Mon, 31 May 2021 17:28:44 +0300
> > From: Eli Zaretskii <eliz@gnu.org>
> > Cc: larsi@gnus.org, 48734@debbugs.gnu.org
> > 
> > > (benchmark-run 1
> > >   (let ((str))
> > >     (with-temp-buffer
> > >       (insert-file-contents "~/2591-0.txt")
> > >       (setq str (string-replace "\n" " " (buffer-string))))
> > >     (print (string-width str)))) ;;;; beware this now hangs
> > > 
> > > I waited a minute for it to finish before killing Emacs.
> > 
> > Why would someone want to measure the visible width of a 550KB string?
> > Is that a real-life use case?
> > 
> > But I think I see the reason, and will try to improve this.
> 
> Turns out I completely misunderstood how find_automatic_composition
> works (because its API is deceptively similar to that of
> find_composition, and the crucial differences aren't documented).  So
> I will need to restructure the code in lisp_string_width to deal
> correctly with automatic compositions; stay tuned.

Eventually, I found a way of fixing lisp_string_width without
restructuring, so the above test case, however unrealistic, now works
reasonably fast.