GNU bug report logs - #49127
Performance degradation in encode_coding_object

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mattias Engdegård <mattiase <at> acm.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 16:23:11 +0300

> From: Mattias Engdegård <mattiase <at> acm.org>
> Date: Wed, 18 Aug 2021 14:21:22 +0200
> Cc: victor.nawothnig <at> icloud.com, 49127 <at> debbugs.gnu.org
> 
> > They could have used text properties instead, no?
> 
> Yes and no. That works for the direction from a point in the buffer but not the other way: go to a specific place in the buffer, such as a definition or all references of something. It could be something selected from a tree in the sidebar etc or be implicit (as in "go to the superclass of the class at point").

Text property search doesn't fit the bill?

> Emacs isn't badly designed -- the marker implementation is fine if we assume there are only a few of them per buffer, which is mostly the case. But it isn't scalable, and also adversely affected by large amounts of garbage markers.

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.

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.  IOW, our design is not evolving enough according to
the needs, not in a small measure because those needs are not always
communicated to us.

Previous Next

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