Re: State of the overlay tree branch?

[Eli Zaretskii]

> From: Sebastian Sturm <address@hidden>
> Date: Fri, 23 Mar 2018 11:15:48 +0100
> 
> > Also, what about my suggestion to count lines in a relative manner,
> > using count-lines from a line with a known number?  You never replied
> > to that suggestion.
> 
> you're right, sorry. In my opinion, a caching mechanism might be a very 
> useful thing to have if it provides further performance benefits on top 
> of what the noverlay branch has to offer. However, since count-lines may 
> not be the only function that has to convert between char and byte 
> positions (or is it?), and since the noverlay branch seems to resolve 
> the overlay issue without having to introduce additional complexity in 
> the elisp layer, implementing a caching mechanism before noverlay is 
> merged into the master branch seems like a premature optimization to me.

It isn't premature optimization, because a buffer could have many
markers even if it has no or only a few overlays.

> Of course this is a layman's opinion (and maybe the case of "few 
> overlays but many markers" is not as pathological as it appears to me); 
> if you think a line number cache should be implemented, I'll go and 
> discuss that with the lsp-mode maintainers (assuming that they are among 
> the heaviest users of line-number-at-pos).

I think the effect should be at least measured before the decision
whether to do that is made.