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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 56682 <at> debbugs.gnu.org, gregory <at> heytings.org, monnier <at> iro.umontreal.ca
Subject: bug#56682: Fix the long lines font locking related slowdowns
Date: Fri, 05 Aug 2022 18:33:53 +0300

> Date: Fri, 5 Aug 2022 17:41:51 +0300
> Cc: monnier <at> iro.umontreal.ca, 56682 <at> debbugs.gnu.org, gregory <at> heytings.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> 
> >> And to address the idea of "unlocking" the narrowing: I think I have
> >> demonstrated that the remaining slowdown can be caused purely by the
> >> length of the buffer and how long 'parse-partial-sexp' takes to parse
> >> it.
> > 
> > No, you haven't demonstrated that.
> 
> Apply the patch for xdisp.c that I have sent previously (it will be at 
> the end of this email too) and recompile Emacs.
> 
> Now try two different scenarios. 1,2a and 1,2b.
> 
> 1. Visit dictionary.json. It will ask you whether to open such big file 
> literally, but after you answer 'y', it will display the beginning of 
> the file quickly.
> 2a) Evaluate (benchmark 1 '(save-excursion (parse-partial-sexp 1 
> (point-max)))), note the reported delay.
> 
> Kill and re-visit the file.
> 
> 1. (same as before)
> 2b) Press M->, note the delay you see.
> 
> The delays in scenarios 1,2a and 1,2b should be ~the same. They are so 
> in my testing.
> 
> Or try this scenario: 1,2a,2b. Step 2b should work instantly here.

How is (parse-partial-sexp 1 (point-max)) related to the issue at
hand?

Previous Next

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