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

[Eli Zaretskii <eliz@gnu.org>]

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