bug#8890: 23.3; message writing slows emacs

[Stefan Monnier]

> I haven't done actual timings, but I'm finding that I have a *very*
> strong perception that when Emacs is writing lots of messages, it slows
> down considerably.

No doubt: Emacs redisplay is among its slowest operations, and while
"message" is handled specially so it doesn't cause a full redisplay,
it's still a slow operation.

> Even if this is only a perception, if it's shared by
> others I think it should be considered a bug.

I think it's largely unavoidable.

> Unless the *Message* buffer is visible, these messages are often
> flashing by so quickly that nobody could hope to see them.

Any such circumstance where messages flash by quickly and repeatedly
(the repetition is important, since otherwise the speed impact is
negligible compared to the redisplay that takes place at the end
of every command anyway) is a bug, so please report them.

> It would be good, IMO, to delay updating the visible message in the
> minibuffer line long enough to be sure that the message just written
> isn't about to be overwritten so fast that the user couldn't read
> it anyway.

We could try and have such a mechanism, yes, but it might be easier to
handle it at some other level.  E.g. the progress-reporter functions
attack one instance of the problem.

> Redisplay always slows down, but on any modern machine displaying only
> the echo area should take a few milliseconds at the most, so I'd be
> surprised if some real slowdown was involved.  If you can show some
> timings, please do, as there could be a bug or misfeature somewhere.

We've already had cases where we found that most of the time was spent
displaying messages.  That's why progress-reporter doesn't call message
at every update.  "A few milliseconds" sounds negligible, but if it's
done at every iteration of a loop whose body takes less than
a millisecond to run (we can do a lot of work in a millisecond on
today's machines), then it's a major slowdown.


        Stefan