|
From: | Gregory Heytings |
Subject: | bug#56393: Actually fix the long lines display bug |
Date: | Sat, 09 Jul 2022 10:50:26 +0000 |
Font lock does slow things down, see the NEWS entry. But it also slows things down on much smaller files (see the long-line-excerpt.xml file I sent you). As I said, to me the slowdown of font locking is a separate problem, as is shown by the fact that turning it off removes the remaining slowdowns in many/most cases. There are in fact four separate problems here:1. slowdowns caused by long lines,2. slowdowns caused by multibyte characters in long lines (which are not solved by solving 1),3. slowdowns caused by font locking,4. slowdowns caused by major and minor modes (pre and post-command hooks and the like).This bug "only" solves 1 and 2. And as I said, I can try to look at 3 if you want, but not now.I'm asking whether applying the "restriction" where we call Vfontification_functions from the display engine won't also solve 3.
It doesn't, see again the long-line-excerpt.xml file I sent you. It is only 30K long, which would be a typical size for a restriction, and editing that file is slow when font locking is on and fast when font locking is off.
What I would do (but I'm pretty sure you wouln't agree with that) is to measure the time taken by fontification-functions in handle_fontified_prop, and whenever that time is above a certain threshold (say 0.25 or 0.5 seconds), to set fontification-functions to nil in that buffer. For example, if you load dictionary.json (with "y") and type C-e, fontification-functions take about 2 seconds to complete.
But fontification-functions are not the only problem here. What I also observe is that, for example, moving in a fontified buffer takes (much) longer than moving in a non-fontified buffer. For example, in long-line.xml, vertical-motion takes about 40 ms backward and 10 ms forward in a non-fontified buffer, and about 180 ms backward and 40 ms forward in a fontified buffer.
[Prev in Thread] | Current Thread | [Next in Thread] |