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 #1558 received at 56682 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Gregory Heytings <gregory <at> heytings.org>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 56682 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#56682: Fix the long lines font locking related slowdowns
Date: Mon, 15 Aug 2022 23:17:46 +0300
On 15.08.2022 22:36, Gregory Heytings wrote:
> 
>>
>> No, I want a simple variable that just gives the size of the narrowed 
>> region, with nil meaning don't narrow at all.
>>
> 
> FWIW, I strongly object to the addition of such a variable (unless it is 
> clearly stated that it is added temporarily and should not be used 
> except for testing purposes).
> 
> Adding such a variable only two weeks after locked narrowing has been 
> introduced means that modes will have little incentive to adapt to that 
> stronger constraint, if they can "fix" whatever problems that constraint 
> might cause by setting that variable to nil in their initialization hooks.

I don't think major modes would take advantage of that var. I hope not, 
at least.

> We did not have enough time yet to explore whether and how syntax-ppss 
> can be improved.

If you wanted the development to take this route, it would have really 
made more sense to hold off on applying the narrowing to 
fontification-functions, keeping font-lock slow-ish in large files. That 
would have encouraged direct work on speeding it up.

But anyway. Suppose we have some more success with syntax-ppss. Two options:

1) parse-partial-sexp is now faster by 10x. That just means we have 10x 
larger files to deal with.

2) We have learned to find a "safe position" in some file types, to 
avoid the full scan from the beginning. It's not hard to implement that 
for JSON and XML, as long as we can stand _some_ imprecision. But there 
will remain all other file types for which nobody has written such logic.

In both cases we fall back to something. And the preceding discussion 
has concluded that that something is narrowing.




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

Previous Next


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