bug#49127: Performance degradation in encode_coding_object

["Mattias Engdegård" <mattiase@acm.org>]

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.