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


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 21:09:54 +0300
> Date: Fri, 5 Aug 2022 20:32:32 +0300
> Cc: 56682 <at> debbugs.gnu.org, gregory <at> heytings.org, monnier <at> iro.umontreal.ca
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> 
> On 05.08.2022 18:33, Eli Zaretskii wrote:
> >> 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>
> >>
> 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?
> 
> I said:
> 
>  >>>> 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.
> 
> You said:
> 
>  >>> No, you haven't demonstrated that.
> 
> ...and now you are asking why we are talking about parse-partial-sexp?

Yes, because a user who visits a file doesn't invoke
parse-partial-sexp.




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.