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

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: 56682 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, Dmitry Gutov <dgutov <at> yandex.ru>
Subject: bug#56682: Fix the long lines font locking related slowdowns
Date: Tue, 16 Aug 2022 10:22:40 -0400

Gregory Heytings [2022-08-16 14:03:16] wrote:
>>> Without assuming that computers have infinitely fast CPUs, that is?
>> If the font-lock rules to use in the buffer depend on whether the first
>> line of the buffer starts with #! or not, then your narrowing will break
>> them even tho they could work perfectly fine in a 1TB buffer without
>> requiring an infinitely fast CPU (since they don't need to scan the whole
>> buffer: just the region of interest plus the first 2 chars).
> Why on earth should a font-lock rule check, inside each redisplay cycle,
> whether the first line of the buffer starts with #! or not?

[ Nitpick: font-lock is not triggered "inside each redisplay cycle".  ]
Because it's simple and efficient.

> Isn't that an information that can, and in fact should, be cached?

"Can" maybe, "should" probably not since managing the cache will be
more trouble than it's worth.

Also, in your case you'd need that info to always be up-to-date, in
which case it's not really a "cache" (since that word usually refers to
something that may be available but isn't guaranteed to be so, and is
re-filled lazily), but a redundant representation of the data (which is
usually more costly to manage).


        Stefan

Previous Next

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