[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 <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.