bug#55205: 28.1.50; completion--replace illegally mutates completion candidates

[Daniel Mendler]

On 5/2/22 19:53, Eli Zaretskii wrote:
>> Date: Mon, 2 May 2022 18:57:06 +0200
>> Cc: monnier@iro.umontreal.ca, larsi@gnus.org, 55205@debbugs.gnu.org
>> From: Daniel Mendler <mail@daniel-mendler.de>
>>
>>> Why is it justified in this case?  How is this case different from any
>>> other case?
>>
>> I am sure that Stefan can give you a more qualified answer than I can. I
>> also don't see a point in this discussion. What is your argument? Do you
>> want to prove me wrong about the issue?
> 
> I just asked a good-faith question.  Why not answer it?

I tried to answer. Stefan tried to answer. But these answers were not
heard. Fortunately there are more answers.

Avoiding mutation in this case is helpful for performance and
efficiency. For example assume that you have many many completion
candidate strings with attached text properties (thousands of them). If
we cannot be sure that the strings are left intact, we have to copy all
these strings first before passing them to the completion system. This
will lead to a noticeable slowdown and severe unnecessary load on the
garbage collector. This really affects the UI badly and noticeably for
the user.

For illustration - in the popular Swiper package (from GNU ELPA), there
is the `swiper` command which has a noticeable startup overhead when
searching through large files, such that it essentially becomes
unusable. This startup overhead is the consequence of allocating a
string for every line of the file.

Furthermore running Swiper multiple times consecutively will lead to
significant memory usage and a garbage collector pause a short while
after. Note that Swiper is not exactly the same scenario I mentioned
above, because the strings are newly allocated. But I want to illustrate
the cost of these allocations and their impact on the UI experience.

I hope this answer is more helpful than the other earlier answers.

Daniel