GNU bug report logs - #56682
Fix the long lines font locking related slowdowns

Previous Next

Package: emacs;

Reported by: Gregory Heytings <gregory <at> heytings.org>

Date: Thu, 21 Jul 2022 18:01:01 UTC

Severity: normal

Done: Gregory Heytings <gregory <at> heytings.org>

Bug is archived. No further changes may be made.

Full log


Message #2175 received at 56682 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 56682 <at> debbugs.gnu.org, Gregory Heytings <gregory <at> heytings.org>,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#56682: feature/improved-locked-narrowing 9dee6df39c: Reworked
 locked narrowing.
Date: Wed, 1 Feb 2023 00:25:00 +0200
On 31/01/2023 23:46, Stefan Monnier wrote:
>> Speaking of additional slowdowns, though, at least in theory -- both
>> syntax-ppss and tree-sitter drop their current parse result when point-min
>> changes.
> FWIW, `syntax-ppss` keeps 2 caches: one for point-min=1 and one for the
> other cases.  So narrowing doesn't quite "drop the current parse", it
> just temporarily ignores it, but recovers it when we exit the narrowing.

Take the scenario for scrolling through a whole file. When the file 
reaches a certain length, the current scheme is to narrow, linearly, to 
successive text chunks of size N, and fontify them.

And since for every chunk point-min will have a new value, it will have 
to re-parse the text from the beginning of the chunk. Even if the cache 
exists already for the whole (unrestricted) buffer.

And even if syntax-ppss-max-span is lower than N (which it currently is 
by default, 20000 vs 500000).




This bug report was last modified 2 years and 8 days ago.

Previous Next


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