bug#49127: Performance degradation in encode_coding_object

[Mattias Engdegård]

18 aug. 2021 kl. 13.43 skrev Eli Zaretskii <eliz@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.