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

[Imran Khan <contact@imrankhan.live>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Imran Khan <contact@imrankhan.live>
>> Date: Sun, 30 May 2021 15:32:16 +0600
>> 
>> > Since you use insert-file-contents-literally, why don't you also make
>> > the temporary buffer unibyte?  That is:
>> >
>> >   (benchmark-run 1
>> >     (let ((str))
>> >       (with-temp-buffer
>> > 	(set-buffer-multibyte nil)  ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>> > 	(insert-file-contents-literally "/tmp/test")
>> > 	(setq str (buffer-string)))
>> >       (string-width str)))
>> >
>> > Or maybe I don't understand your real-life use case?  Because if you
>> > treat the file as a raw bytestream, why do you need to compute the
>> > width of its text?
>> 
>> I would agree, my example was pointlessly contrived. For what it's
>> worth, `insert-file-contents` exhibits same poor performance, and that's
>> used by code in the wild (e.g. deft-mode, though I am sceptical if they
>> should be needing to call `string-width` on entire buffer text either).
>> 
>> Personally I am now going to use your `(set-buffer-multibyte nil)`
>> suggestion to patch their code for myself (so thanks for this). Since
>> I have no idea about the internal complexity of `string-width` or what
>> should be justified performance expectation, I would let you decide if
>> this is a bug or not.
>
> I'm not yet sure whether this is a real problem, because I don't
> really understand the relation between your example code and what you
> really need to do in deft-mode.  Specifically, generating random
> characters isn't something that usually happens in real life.
>
> So could you perhaps explain what you are using string-width for in
> deft-mode, and what kind of text are you measuring there in your
> real-life situations?
>
> Thanks.
>
> P.S. Please use Reply All to keep the bug address on the CC list.

Basically deft-mode takes a folder full of normal org-mode files, and
constructs a pretty "dashboard" view of the folder where you can browse,
search, filter the files in said folder (and many other features).

The dashboard UI uses `string-width` to calculate how much space is to
be allocated relative to window width to display metadata like file
title, file content summary, mtime etc for each file per line. This is
dynamic, the components size adjusts to window width change. Perhaps the
screenshot they have in their project page would be more descriptive:

https://github.com/jrblevin/deft

Org-mode files typically have unicode chars in them. So when deft-mode
uses `string-width` to construct view of file content part, it
hangs. I think the performance problem here is exacerbated because
deft-mode is stripping all vertical whitespace to squash the content to
show in a single line summary view, before calling `string-width`.

P.S. I am not involved with deft-mode, merely a user with moderately
sized utf-8 org-mode files. But if you think it's their UI
implementation ought be reworked, I can forward it to them.