bug#49127: Performance degradation in encode_coding_object

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

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