GNU bug report logs - #70784
Abolish string resizing

Previous Next

Full log

View this message in rfc822 format

From: Po Lu <luangruo <at> yahoo.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Mattias Engdegård <mattias.engdegard <at> gmail.com>, 70784 <at> debbugs.gnu.org
Subject: bug#70784: Abolish string resizing
Date: Mon, 06 May 2024 12:41:59 +0800

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> Actually, it's not "immemorial", it's just old:
>
>     commit 3c9de1afcde82a99137721436c822059cce79b5b
>     Author: Kenichi Handa <handa <at> gnu.org>
>     Date:   Fri Jul 21 06:45:30 2000 +0000

That's _23_, approaching 24 years, in the past, or 1 generation exactly.
To put this into perspective, a mere 2 years and 7 months after the
introduction of multibyte strings.

>
>         (Faset): Allow storing any multibyte character in a string.  Convert
>         unibyte string to multibyte if necessary.
>
> IOW, since Emacs-21.1.

Only two releases after the distinction between multibyte and unibyte
strings was introduced.  Evidently, this departure from traditional
array behavior was seen as a misdesign at the time, and we should know
better than to second-guess old design decisions, especially those from
a past when computer memory and performance were far scarcer commodities
than today.

> As for improvements, like a lot of refactoring and maintenance work,
> there isn't any immediate benefit.  But it's a "feature" which is *very*
> rarely used (thank god: it makes a notionally constant time operation
> take time proportional to the size of the string, so if it were used
> often we would have heard complaints about the poor performance) and
> which imposes pretty significant implementation constraints, so it's
> definitely detrimental to long term evolution.

Placing quotation marks around the word "feature" does not make it any
less of a feature, and if reports of performance woes be the judge of
whether a feature is sufficiently disused to justify removal, then, why,
virtually all (vastly underreported) sub-optimal code in Emacs would be
eligible for immediate deletion attended by irritating pop-up warnings.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.