bug#15841: Display bugs with cache-long-lines non-nil

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: 15841@debbugs.gnu.org,  nbtrap@nbtrap.com
> Date: Mon, 11 Nov 2013 04:39:56 +0100
> 
> The culprit was my own code: it placed myriads of invisible overlays
> with no properties into the buffer.  Under these extreme circumstances,
> `line-number-at-pos' indeed gets extremely slow at the end of my 10000
> lines buffer: one invocation needs over a second.  I saw that with elp
> as well as with profiler.  Setting `cache-long-scans' to nil (or
> removing the overlays) cures this.

Can you show some simple enough code that puts so many overlays, and
has this effect?  It sounds like some optimization is in order.

> Although this is a corner case, I wonder why overlays slow down
> `line-number-at-pos' so much for `cache-long-scans' non-nil - is that
> expected?

I don't know.  Armed with a simple test case, I will look into this
and see what I find.

> Because, when I use this:
> 
> (defmacro my-measure-time (expr)
>   "Eval EXPR, display how much time it took."
>   (with-gensyms (time)
>     `(let ((,time (current-time)))
>        ,expr
>        (message "%s secs"
>           (float-time (time-subtract (current-time) ,time))))))
> 
> and evaluate (my-measure-time (line-number-at-pos)) manually with M-:
> (in the same situation), it shows a very tiny value.  But I'm sure that
> from code, `line-number-at-pos' really lasts over a second.  Strange, I
> don't understand it.

Redisplay is indeed a likely suspect, but still cache-long-scans
somehow comes into play.

Thanks.