Date: Fri, 11 Jun 2021 20:06:30 +0000
Cc: Stefan Monnier <monnier@iro.umontreal.ca>, dancol@dancol.org,
rudalics@gmx.at, rms@gnu.org, emacs-devel@gnu.org
From: Alan Mackenzie <acm@muc.de>
Why do we have a problem? If the time taken to fontify a window is less
than the auto-repeat time (the two times are close on a modern machine),
this is surely not a problem for somebody with such a machine. It could
be a problem for somebody with a slower machine, or running an
unoptimised Emacs.
It is a problem given how much the current fast machines can do during
that time. At 3 GHz, 30 msec of CPU time is equivalent to 100 million
machine instructions.
That is much better, but still too slow, IMO. Think: it's the time
that it takes us to fontify a single windowful, only a couple of
dozens of lines. Why does it take so long?
It does a very thorough job.
AFAIU, sm-c-mode doesn't. And it still takes tens of milliseconds.
For example, one bug fix from many years
ago that I remember involved the fontification of foo in the following:
....
int bar;
} foo;
What face should foo have? To answer that, you've got to go back over
the brace expression to see what's there. If it's
struct foo
{
int baz;
....
, we need font-lock-variable-name-face for foo. On the other hand, if we
have
typedef struct foo
{
int baz;
....
, we need font-lock-type-face. Before the bug fix, foo just got variable
name face. scan-lists backward over the brace expression takes time,
particularly for something the size of struct frame or even bigger.
We should either find a way of making this analysis faster, or give up
on fontifying these two cases differently. It is IMO unacceptable
that redisplay is slowed down so much by mode-specific fontifications.