GNU bug report logs -
#70784
Abolish string resizing
Previous Next
Full log
View this message in rfc822 format
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>
> From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
> Date: Sun, 5 May 2024 14:33:51 +0200
>
> The Elisp ability to resize strings is high-cost, low-benefit, so we should abolish it.
>
> Strings are performance-critical, and the split allocation (fixed-size metadata + variable-size data) and its indirections are not free. This is one reason why strings are comparatively expensive in Elisp compared to other languages.
>
> With MPS there is even no use for the special-purpose string data defragger in the current GC.
>
> String resizing occurs in exactly one place: `aset` on strings, and then only when the mutation alters the string size, in either of two cases:
>
> * When a unibyte string byte is set to a non-byte value (> 255), which also forces the string to become multibyte.
> * When a multibyte string char is set to a char of different length.
>
> String mutation itself is very rare these days, and resizing string mutation exceptionally so.
>
> Best and simplest would be to just turn resizing `aset` on strings into an error now. As an alternative, we could start warning about it now and make it an error in the next release. The (trivial) patches exist.
How many places in our own sources call aset on strings?
>
> Note that this is not a proposal for abolishing string mutation in general. For example, `clear-string` would still work on any string, as would arbitrary closed mutations on unibyte strings and on ASCII multibyte strings.
I'm not yet sure this is a good idea, but one thing I'm sure: it is
not for Emacs 30. So if we decide to go this way, let's delay
merging the changes until after the emacs-30 branch is cut, which
should happen in a week or two.
Thanks.
This bug report was last modified 141 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.