GNU bug report logs - #16830
[Bug] 24.3.50; massive slow down in forward-line

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 16830 <at> debbugs.gnu.org, stefan.hahn <at> s-hahn.de, monnier <at> iro.umontreal.ca
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 <rudalics <at> gmx.at>
> CC: "Stefan-W. Hahn" <stefan.hahn <at> s-hahn.de>, 
>  Stefan Monnier <monnier <at> iro.umontreal.ca>,
>  16830 <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.