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

Previous Next

Full log

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

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: Re: bug#56682: Fix the long lines font locking related slowdowns
Date: Sat, 06 Aug 2022 14:17:55 +0300

> 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".

> > 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.

Previous Next

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