bug#8890: 23.3; message writing slows emacs

[Dave Abrahams <dave@boostpro.com>]

on Fri Sep 16 2011, Stefan Monnier <monnier-AT-iro.umontreal.ca> wrote:

>>> "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.
>> Then programmers who run those loops should update the progress less
>> aggressively.  Redisplay (and infrastructure in general) lack the
>> context that would allow them to make good decisions as to when defer
>> repeated display.  Only the calling application can know that.
>
> Indeed.  The main problem with changing `message' is that if it is
> called too soon after the previous `message' we can't easily say "don't
> display this one" since there may not be any subsequent message coming,
> so we'd have to stash the last undisplayed message and then try and
> figure out good places/times to cause them to be displayed.

Well, the `obvious' good place/time is at next idle if no further
messages have come along to stomp on the previous one.

> So the general approach to fixing those problems is to say "use
> progress-reporter-update" since this function has the advantage of
> knowing that there will be a `progress-reporter-done' at some later
> point, which allows it to skip a message without worries.

Hm.  So there *is* a builtin functionality for this... well, that's
good.  Sorry if I've wasted everyone's time on this.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com