GNU bug report logs - #55205
28.1.50; completion--replace illegally mutates completion candidates

Previous Next

Package: emacs;

Reported by: Daniel Mendler <mail <at> daniel-mendler.de>

Date: Sun, 1 May 2022 08:29:02 UTC

Severity: normal

Found in version 28.1.50

Done: Daniel Mendler <mail <at> daniel-mendler.de>

Bug is archived. No further changes may be made.

Full log


Message #152 received at 55205 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, monnier <at> iro.umontreal.ca, 55205 <at> debbugs.gnu.org
Subject: Re: bug#55205: 28.1.50; completion--replace illegally mutates
 completion candidates
Date: Mon, 2 May 2022 20:35:56 +0200
On 5/2/22 19:53, Eli Zaretskii wrote:
>> Date: Mon, 2 May 2022 18:57:06 +0200
>> Cc: monnier <at> iro.umontreal.ca, larsi <at> gnus.org, 55205 <at> debbugs.gnu.org
>> From: Daniel Mendler <mail <at> 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




This bug report was last modified 233 days ago.

Previous Next


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