bug#16830: [Bug] 24.3.50; massive slow down in forward-line

[Eli Zaretskii <eliz@gnu.org>]

> Date: Tue, 11 Mar 2014 09:08:55 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: "Stefan-W. Hahn" <stefan.hahn@s-hahn.de>, 
>  Stefan Monnier <monnier@iro.umontreal.ca>,
>  16830@debbugs.gnu.org
> 
>  > Until we can dynamically estimate the line length and turn the cache
>  > on only for long lines, I suggest to leave the default ON, and install
>  > the patches below.  My reasoning is that in most situations the
>  > slow-down is negligible, while for very long lines the speedup can be
>  > significant.
> 
> In general I inspect long lines only in bug reports.  Is that sufficient
> reason to not follow the advice
> 
>     There is no reason to set this to nil except for debugging purposes.
> 
> after your patch is applied?

Actually, I suggest to only change the default if you ever see a
tangible difference with and without the cache.

If you review the timings I posted, you will realize that a single
call to find_newline takes a fraction of a microsecond on a reasonably
modern machine, so unless you use code that calls forward-line with a
very large argument, like hundreds of thousands, you will never see
the difference.

Also, turning off cache-long-scans disables not only the newline
cache, but also 2 other caches, at least one of which (the bidi
paragraph start cache) might be important for redisplay speed, and
doesn't suffer from the slowdown I discovered with the newline cache,
because the way we use that cache is very different.