GNU bug report logs -
#70784
Abolish string resizing
Previous Next
Full log
View this message in rfc822 format
Mattias Engdegård <mattias.engdegard <at> gmail.com> writes:
> The Elisp ability to resize strings is high-cost, low-benefit, so we
> should abolish it.
What is the improvement to be had by "abolishing" this immemorial
feature?
If it's a notional increase in Lisp evaluation performance, please stop.
Emacs Lisp is not a hot-rod where crucial, fundamental facilities are
dispensable in the face of a performance improvement (which is anything
but a certainly at this early stage) of a few percent or similarly
marginal value on contrived benchmarks testing scenarios unlikely to be
encountered in real Lisp code.
MPS is no justification for degrading the capabilities of the existing
GC, if for no other reason than its being inoperable on systems beyond
the limited selection whose support its developers consider a priority,
and the increase in memory consumption it brings (e.g. it will never
function on Android 13, because the C library's sigaction wrapper is
insufficient to enable MPS and JVM trap handlers to coexist). What's
more, memory consumption is an aspect that should not be sacrificed for
minor gains in performance, with a program that is designed to be a good
citizen on systems old and new.
Is it only I who am tired of these proposals for complete upheavals
that, somehow, Emacs has fared just fine without, for generations past?
It's precisely this attitude that begins to inspire thoughts of
departure. Backwards-compatibility is an obligation that cannot be
evaded by means of warnings, which instead serve to annoy and antagonize
users, whose only wish is that Emacs leave them in peace.
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.