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

Previous Next

Full log

View this message in rfc822 format

From: Gregory Heytings <gregory <at> heytings.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 56682 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, monnier <at> iro.umontreal.ca
Subject: bug#56682: Fix the long lines font locking related slowdowns
Date: Sun, 07 Aug 2022 20:21:04 +0000

>> No, isearch is entirely agnostic about font locking.
>
> I wonder where it spends those 2 seconds, then.
>

The answer is simple: it is not isearch that is slow, it's redisplay that 
is slowed down by font locking.

>> It's yet another test meant to test Emacs' responsiveness, and it is as 
>> "objective" as possible: does Emacs choke or does it not?
>
> It's not a test of font-lock's performance, however. Because it compares 
> that to a process that's internal to Emacs as well (moving across the 
> buffer with C-v). Like, the faster we're able to make the latter 
> command, the faster font-lock has to be to keep up. As an objective 
> test, it's not meaningful.
>

It is not by itself a test of font locking performance.  It becomes one 
when you compare it with what you see (a) when font locking is completely 
disabled, and (b) when font locking is enabled by constrained by a locked 
narrowing.

Previous Next

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