GNU bug report logs - #49127
Performance degradation in encode_coding_object

Previous Next

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 14:21:22 +0200

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

>> 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.
> 
> 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").

The alternative is to use plain offsets instead, and update them inside buffer-change callback functions -- but then we are essentially doing exactly what the Emacs marker implementation would be doing, only in Elisp instead of C so probably slower, unless we use more clever data structures.

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.

Previous Next

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