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

Previous Next

Full log

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 56682 <at> debbugs.gnu.org, gregory <at> heytings.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#56682: Fix the long lines font locking related slowdowns
Date: Sat, 6 Aug 2022 23:59:10 +0300

On 06.08.2022 14:17, Eli Zaretskii wrote:
>> Date: Sat, 6 Aug 2022 13:50:41 +0300
>> Cc: 56682 <at> debbugs.gnu.org, gregory <at> heytings.org, monnier <at> iro.umontreal.ca
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>>
>>>> I'm not seeing any particular sluggishness in these operations when
>>>> visiting dictionary.json.
>>>
>>> Numbers, please.  You have a very fast machine, so what doesn't look
>>> sluggish on your system could very well be so on others.
>>
>> How do you measure these operations including the redisplay lag?
> 
> By timing them.  With benchmark-run or similar, if it isn't slow
> enough to be measured "by hand".

How do I time 'M-x'?

Anyway, here are some numbers:

(benchmark 1 '(next-line 1)) =>
Elapsed time: 0.035137s
Elapsed time: 0.061863s
Elapsed time: 0.027261s
(benchmark 1 '(cua-scroll-down 1)) =>
Elapsed time: 0.049362s
Elapsed time: 0.050060s
(benchmark 1 '(cua-scroll-up 1)) =>
Elapsed time: 0.012383s
Elapsed time: 0.039984s
(benchmark 1 '(recenter-top-bottom 1)) =>
Elapsed time: 0.042014s
Elapsed time: 0.013934s

I get very similar numbers on these operations with unmodified master in 
this file.

>>> Linear scaling is less optimal than O(0), which is what the current
>>> solution produces.
>>
>> Correct syntax highlighting requires parsing the buffer from the
>> beginning. Otherwise we get random results, essentially.
>>
>> Just like depicted on my latest screenshot for downloadify.js: the
>> beginning of the narrowed region ended up inside a string, and as a
>> result several screenfuls were entirely mis-fontified, with strings and
>> non-strings inverted.
> 
> Yes, and IMNSHO responsiveness is more important than correctness in
> these cases.

That's why I suggested that, possibly after some further optimization 
work on parse-partial-sexp and syntax-propertize, we decide which 
initial length of the file we can fontify correctly with decent speed. 1 
MB, or 10 MB, something like that.

And of course make that customizable.

Previous Next

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