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

View this message in rfc822 format

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: bug#49127: Performance degradation in encode_coding_object
Date: Wed, 18 Aug 2021 15:32:11 +0200

18 aug. 2021 kl. 15.23 skrev Eli Zaretskii <eliz <at> gnu.org>:

> Text property search doesn't fit the bill?

Oh it does, except that it's linear in the size of the buffer, and that doesn't really scale either. For a single interactive lookup this might not be too bad but there might be programmatic uses that iterate.

> These situations usually mean we lack some infrastructure, and the
> Lisp program uses what's available, with bad results.  A better
> solution is to design and implement the missing infrastructure
> instead.

Could be, but markers is one type of infrastructure, and implementing something else for the same purpose is a bit of a waste compared to just making markers faster.

> The problem with Emacs is not the design, it's that in many cases,
> instead of extending the design where something is missing, Lisp
> programmers tend to use the existing features outside of their
> intended purpose.

Very true. We have probably done our job for the time being, but let's keep our eyes open for uses (legitimate or not) that stress the marker system to the point of disappointment, and consider what to do then.
This bug report was last modified 3 years and 273 days ago.

Previous Next

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