GNU bug report logs - #8890
23.3; message writing slows emacs

Previous Next

Full log

View this message in rfc822 format

From: Dave Abrahams <dave <at> boostpro.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 8890 <at> debbugs.gnu.org
Subject: bug#8890: 23.3; message writing slows emacs
Date: Fri, 16 Sep 2011 11:11:56 -0400

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.