bug#8890: 23.3; message writing slows emacs

[Dave Abrahams]

on Sat Sep 17 2011, Lars Magne Ingebrigtsen <larsi-AT-gnus.org> wrote:

> Dave Abrahams <dave@boostpro.com> writes:
>
>>> 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.
>
> I didn't know about progress-reporter, so my time wasn't wasted, at
> least.  :-)
>
> But I wonder whether a simpler, more general function would be
> possible.  If we're outputting stuff that's not a percentage,
> progress-reporter doesn't help much.
>
> `message' could work as follows:
>
> If it's been less than (say) 50th of a second since the previous
> message, then don't message anything.  However, set up a timer in a
> 100th of a second's time to display that message -- if nothing else has
> been displayed in the mean time.

Technically, that 100th of a second could be arbitrarily long:

,----[ (info "(elisp)Timers") ]
|    Emacs cannot run timers at any arbitrary point in a Lisp program; it
| can run them only when Emacs could accept output from a subprocess:
| namely, while waiting or inside certain primitive functions such as
| `sit-for' or `read-event' which _can_ wait.  Therefore, a timer's
| execution may be delayed if Emacs is busy.  However, the time of
| execution is very precise if Emacs is idle.
`----

However, that might not be such a bad thing.

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