GNU bug report logs - #49127
Performance degradation in encode_coding_object

Previous Next

Package: emacs;

Reported by: Victor Nawothnig <victor.nawothnig <at> icloud.com>

Date: Sun, 20 Jun 2021 08:19:03 UTC

Severity: normal

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log

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

From: Mattias Engdegård <mattiase <at> acm.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 49127 <at> debbugs.gnu.org, victor.nawothnig <at> icloud.com
Subject: Re: bug#49127: Performance degradation in encode_coding_object
Date: Wed, 18 Aug 2021 13:04:12 +0200

17 aug. 2021 kl. 19.16 skrev Eli Zaretskii <eliz <at> gnu.org>:

> It's a problem to have many markers in a buffer.  Not only for code
> that searches them linearly, but also for stuff like converting
> between character and byte positions, something that we do a lot in
> the most inner loops of our code.  Lisp programs that produce gobs of
> markers should be ideally redesigned not to do so.

I agree; the haskell-mode usage was misguided in this respect. Marker-intensive modes could still be justified occasionally: consider an index of all definitions and uses of each variable, function and type in a program, produced by an expensive compilation that cannot be re-run for each little change. This could easily amount to thousands of markers in a big file.

>  Unless we change
> the way we store markers to make that a non-issue.

We probably should but I agree that marker reduction should be the first remedy to try.
Improving the GC so that it's cheaper to run frequent collections would also help in the common case where most markers are dead (as in this case).
This bug report was last modified 3 years and 274 days ago.

Previous Next

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