Re: Speed of keyboard macro execution?

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 10 Dec 2015 12:33:12 -0500
> From: "Perry E. Metzger" <perry@piermont.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> 
> On Thu, 10 Dec 2015 18:27:49 +0100 David Engster
> <deng@randomsample.de> wrote:
> > Perry E. Metzger writes:
> > > I don't know if it was disingenuous or not, but I think that being
> > > able to improve performance would not be a bad thing.
> > 
> > No one is claiming that. AFAIK, the very-long-line problem is not
> > easy to fix.
> 
> Perhaps it isn't. Looking at the old thread, it seems like the bidi
> code is one of the culprits.

No, if this is your conclusion, you are not reading it right.  The
bidi code makes the awfully slow cases slower, but they are awfully,
unbearably slow even when bidi is turned off.  IOW, in practical
terms, bidi didn't change anything in those cases: half the infinity
is still infinity.

> OTOH, if I read this right and the problem is partially slow
> redisplay, I'm wondering why the redisplay code needs to be involved
> at all if a long keyboard macro is being run. Perhaps there should
> be some way to suspend redisplay, perform the macro, and then
> restart it? I have to admit I haven't looked at the code involved
> and it might be utterly infeasible.

This I can explain.  "Redisplay" comes into play not only for actually
redrawing the screen, it also comes into play when, e.g., a command
moves cursor down, as in C-n.  With (the default) line-move-visual
mode, Emacs no longer has an easy way of knowing what character is
directly below the current one, what with all the variable-pitch fonts
and long lines broken between several screen lines.  The only way of
finding out where is "one visual line down" is to _simulate_
redisplay.  IOW, Emacs runs code that does exactly what redisplay
does, but without displaying anything; it just accumulates pixel
coordinates until it finds itself one visual line down.

Any keyboard macro that moves point will at some point invoke this
code, because moving point in a variable-pitch multi-font display is a
hard problem, and this is even before we consider complications like
display properties, overlay strings, embedded images, and the other
calamities.