|
From: | Gregory Heytings |
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.
[Prev in Thread] | Current Thread | [Next in Thread] |