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

[Imran Khan]

Eli Zaretskii <eliz@gnu.org> writes:

>> 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.

I have tested and can confirm it works and solves my issues with
deft-mode. Thanks a lot Eli, I am grateful for all your work.