[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eli Zaretskii
Subject: bug#16830: [Bug] 24.3.50; massive slow down in forward-line
Date: Tue, 11 Mar 2014 19:03:19 +0200

> Date: Tue, 11 Mar 2014 09:08:55 +0100
> From: martin rudalics <address@hidden>
> CC: "Stefan-W. Hahn" <address@hidden>, 
>  Stefan Monnier <address@hidden>,
>  address@hidden
>  > 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]