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

Previous Next

Package: emacs;

Reported by: Dave Abrahams <dave <at> boostpro.com>

Date: Sat, 18 Jun 2011 16:46:02 UTC

Severity: normal

Found in version 23.3

Fixed in version 29.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: dave <at> boostpro.com, 8890 <at> debbugs.gnu.org
Subject: bug#8890: 23.3; message writing slows emacs
Date: Fri, 16 Sep 2011 10:20:05 -0400
>> "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.

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.


        Stefan




This bug report was last modified 3 years and 45 days ago.

Previous Next


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