bug#10539: 24.0.92; low display-time-interval makes Emacs slow

bug#10539: 24.0.92; low display-time-interval makes Emacs slow

[Michael Heerdegen]

Hello,

in emacs -Q, set `display-time-interval' to 1 and enable
`display-time-mode'.

The docstring of `display-time-interval' says "Seconds between updates
of time in the mode line.".  Ok, fine.  The doc of
`display-time-string-forms' includes an example which makes
`display-time-mode' show seconds.  So, the user may think setting
`display-time-interval' to 1 is a good idea.

But it is currently not, on the contrary.

First of all, `display-time-update' is a long, complex function.
Running only its calculations every second consumes some percent CPU by
itself.

Second, the doc of `display-time-update' says

  Update the display-time info for the mode line.
  However, don't redisplay right now.

But it _does_ redisplay, it calls `force-mode-line-update' explicitly at
the end of the code!

If I redefine `display-time-update' so that it doesn't call
`force-mode-line-update', the update of the time in the mode-line
surprisingly still works, I get an update every second.  So, maybe the
call to `force-mode-line-update' can be removed.

Now I disable global font lock and such CPU eating minor mode stuff.  I
visit my ~/.newsrc.eld which has 647k.  My CPU consumption gets nearly
100%, it takes several seconds until q (`View-quit') gets processed.  If
I visit that file with `display-time-mode' off, that doesn't happen.

So, at the end, you could try to make `display-time-mode' more
effective.  If `display-time-update' does redisplay, then the doc should
say so.  And if we can't improve things, then the docstring of
`display-time-interval' should say that low values are 
deprecated because they decrease Emacs' performance.


Thanks,

Michael.



In GNU Emacs 24.0.92.1 (i486-pc-linux-gnu, GTK+ Version 3.2.3)
 of 2012-01-11 on zelenka, modified by Debian
 (emacs-snapshot package, version 1:20120111-1)
Windowing system distributor `The X.Org Foundation', version 11.0.11102902
configured using `configure  '--build' 'i486-linux-gnu' '--host' 'i486-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--localstatedir=/var' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes' '--enable-locallisppath=/etc/emacs-snapshot:/etc/emacs:/usr/local/share/emacs/24.0.92/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.0.92/site-lisp:/usr/share/emacs/site-lisp' '--without-compress-info' '--with-crt-dir=/usr/lib/i386-linux-gnu/' '--with-x=yes' '--with-x-toolkit=gtk3' '--with-imagemagick=yes' 'build_alias=i486-linux-gnu' 'host_alias=i486-linux-gnu' 'CFLAGS=-DDEBIAN -DSITELOAD_PURESIZE_EXTRA=5000 -g -O2''

Important settings:
  value of $LC_ALL: de_DE.utf8
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: C
  value of $LANG: de_DE.utf8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

bug#10539: 24.0.92; low display-time-interval makes Emacs slow

[Glenn Morris]

Michael Heerdegen wrote:

> Second, the doc of `display-time-update' says
>
>   Update the display-time info for the mode line.
>   However, don't redisplay right now.
>
> But it _does_ redisplay, it calls `force-mode-line-update' explicitly at
> the end of the code!

Looking at the history, the code used to have a (sit-for 0.0) after the
force-mode-line-update. The "don't redisplay" part was added when the
sit-for was removed. I confess that I don't really understand
force-mode-line-update [1]. The name makes sense, but not much else.
The manual says:

 -- Function: force-mode-line-update &optional all
     Force redisplay of the current buffer's mode line and header line.
     The next redisplay will update the mode line and header line based
     on the latest values of all relevant variables.

which seems contradictory to me ("force redisplay" + "next redisplay").

Maybe the "don't redisplay" refers to the lack of the ALL argument?


[1] eg http://lists.gnu.org/archive/html/emacs-devel/2010-05/msg00581.html

bug#10539: 24.0.92; low display-time-interval makes Emacs slow

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Fri, 27 Jan 2012 16:30:44 -0500
> Cc: 10539@debbugs.gnu.org
> 
> Michael Heerdegen wrote:
> 
> > Second, the doc of `display-time-update' says
> >
> >   Update the display-time info for the mode line.
> >   However, don't redisplay right now.
> >
> > But it _does_ redisplay, it calls `force-mode-line-update' explicitly at
> > the end of the code!
> 
> Looking at the history, the code used to have a (sit-for 0.0) after the
> force-mode-line-update. The "don't redisplay" part was added when the
> sit-for was removed. I confess that I don't really understand
> force-mode-line-update [1]. The name makes sense, but not much else.

The discussion that you refer to was about the optional ALL argument.
It said nothing about force-mode-line-update itself or its effect,
apart of that.

> The manual says:
> 
>  -- Function: force-mode-line-update &optional all
>      Force redisplay of the current buffer's mode line and header line.
>      The next redisplay will update the mode line and header line based
>      on the latest values of all relevant variables.
> 
> which seems contradictory to me ("force redisplay" + "next redisplay").

Would the following wording make it less confusing/contradictory?

  Force next redisplay cycle to update the current buffer's mode line
  and header line, based on the latest values of all the relevant
  variables.

> Maybe the "don't redisplay" refers to the lack of the ALL argument?

No, it refers to the fact that force-mode-line-update does not trigger
redisplay, it just sets some internal variable that would force
recomputation and redisplay of the mode line during the next redisplay
cycle, whenever that happens.  IOW, it prevents Emacs from deciding
that nothing changed and therefore nothing on the screen should be
redrawn.

bug#10539: 24.0.92; low display-time-interval makes Emacs slow

[martin rudalics]

 > Would the following wording make it less confusing/contradictory?
 >
 >   Force next redisplay cycle to update the current buffer's mode line

A buffer doesn't have a mode or header line.  And a body like

   (if all (with-current-buffer (other-buffer)))
   (set-buffer-modified-p (buffer-modified-p)))

indicates that this function exclusively relies on obscure side effects
which are not documented anywhere.

martin

bug#10539: 24.0.92; low display-time-interval makes Emacs slow

[Glenn Morris]

Eli Zaretskii wrote:

> Would the following wording make it less confusing/contradictory?
>
>   Force next redisplay cycle to update the current buffer's mode line
>   and header line, based on the latest values of all the relevant
>   variables.

Yes thanks. Plus something similar for the function's doc-string.
So it doesn't actually "force redisplay", it just marks things to be
updated the next time redisplay happens to occur (?).

bug#10539: 24.0.92; low display-time-interval makes Emacs slow

[Glenn Morris]

martin rudalics wrote:

> indicates that this function exclusively relies on obscure side effects
> which are not documented anywhere.

Yes, that was basically my point. Which is presumably why it does other
stuff that has no obvious relation to mode-lines ("forces recomputation
of the menu bar menus and the frame title"). But this is probably
off-topic for this report.

bug#10539: 24.0.92; low display-time-interval makes Emacs slow

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: michael_heerdegen@web.de,  10539@debbugs.gnu.org
> Date: Sat, 28 Jan 2012 14:42:18 -0500
> 
> Eli Zaretskii wrote:
> 
> > Would the following wording make it less confusing/contradictory?
> >
> >   Force next redisplay cycle to update the current buffer's mode line
> >   and header line, based on the latest values of all the relevant
> >   variables.
> 
> Yes thanks. Plus something similar for the function's doc-string.

Will do.

> So it doesn't actually "force redisplay", it just marks things to be
> updated the next time redisplay happens to occur (?).

Yes, exactly.

bug#10539: 24.0.92; low display-time-interval makes Emacs slow

[Glenn Morris]

Eli Zaretskii wrote:

>> So it doesn't actually "force redisplay", it just marks things to be
>> updated the next time redisplay happens to occur (?).
>
> Yes, exactly.

Thanks. Next question that occurs: the display-time stuff is a global
indicator that, when it needs updating, should be updated in all visible
mode-lines. So how does (force-mode-line-update) with no ALL argument do
anything useful in this case?

bug#10539: 24.0.92; low display-time-interval makes Emacs slow

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: michael_heerdegen@web.de,  10539@debbugs.gnu.org
> Date: Sat, 28 Jan 2012 15:51:54 -0500
> 
> Next question that occurs: the display-time stuff is a global
> indicator that, when it needs updating, should be updated in all visible
> mode-lines. So how does (force-mode-line-update) with no ALL argument do
> anything useful in this case?

I think force-mode-line-update nowadays always forces update of all
visible mode lines, not just the one of the current buffer.

Calling force-mode-line-update with ALL non-nil forces a more thorough
redisplay (because it sets a flag which causes redisplay not to trust
the contents of the displayed windows, not just their mode lines).

IOW, (force-mode-line-update t) is a way to force the next redisplay
cycle do a more thorough job, it has nothing to do with mode lines per
se.

bug#10539: 24.0.92; low display-time-interval makes Emacs slow

[Glenn Morris]

Eli Zaretskii wrote:

> I think force-mode-line-update nowadays always forces update of all
> visible mode lines, not just the one of the current buffer.
>
> Calling force-mode-line-update with ALL non-nil forces a more thorough
> redisplay (because it sets a flag which causes redisplay not to trust
> the contents of the displayed windows, not just their mode lines).
>
> IOW, (force-mode-line-update t) is a way to force the next redisplay
> cycle do a more thorough job, it has nothing to do with mode lines per
> se.

I think it would be good if you could document this, because it's
basically impossible to figure out what this function actually does from
looking at its lisp definition.

bug#10539: 24.0.92; low display-time-interval makes Emacs slow

[Drew Adams]

> > IOW, (force-mode-line-update t) is a way to force the next redisplay
> > cycle do a more thorough job, it has nothing to do with mode lines per
> > se.
> 
> I think it would be good if you could document this, because it's
> basically impossible to figure out what this function 
> actually does from looking at its lisp definition.

+1

bug#10539: 24.0.92; low display-time-interval makes Emacs slow

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: michael_heerdegen@web.de,  10539@debbugs.gnu.org
> Date: Sun, 29 Jan 2012 01:07:24 -0500
> 
> Eli Zaretskii wrote:
> 
> > I think force-mode-line-update nowadays always forces update of all
> > visible mode lines, not just the one of the current buffer.
> >
> > Calling force-mode-line-update with ALL non-nil forces a more thorough
> > redisplay (because it sets a flag which causes redisplay not to trust
> > the contents of the displayed windows, not just their mode lines).
> >
> > IOW, (force-mode-line-update t) is a way to force the next redisplay
> > cycle do a more thorough job, it has nothing to do with mode lines per
> > se.
> 
> I think it would be good if you could document this, because it's
> basically impossible to figure out what this function actually does from
> looking at its lisp definition.

I don't mind, but I'd like Chong's and Stefan's opinion on this first.
The way the function is (was) implemented it exploits intimate
knowledge about redisplay's inner workings.  Maybe we should simply
expose to Lisp the corresponding internal variables instead, or
provide Lisp primitive functions to set them?

bug#10539: 24.0.92; low display-time-interval makes Emacs slow

[martin rudalics]

 > Calling force-mode-line-update with ALL non-nil forces a more thorough
 > redisplay (because it sets a flag which causes redisplay not to trust
 > the contents of the displayed windows, not just their mode lines).

Can you tell me which flag (with-current-buffer (other-buffer)) sets?

martin

bug#10539: 24.0.92; low display-time-interval makes Emacs slow

[Eli Zaretskii]

> Date: Sun, 29 Jan 2012 18:51:42 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: Glenn Morris <rgm@gnu.org>, michael_heerdegen@web.de, 
>  10539@debbugs.gnu.org
> 
>  > Calling force-mode-line-update with ALL non-nil forces a more thorough
>  > redisplay (because it sets a flag which causes redisplay not to trust
>  > the contents of the displayed windows, not just their mode lines).
> 
> Can you tell me which flag (with-current-buffer (other-buffer)) sets?

windows_or_buffers_changed, AFAIR.

bug#10539: 24.0.92; low display-time-interval makes Emacs slow

[Stefan Monnier]

> I don't mind, but I'd like Chong's and Stefan's opinion on this first.
> The way the function is (was) implemented it exploits intimate
> knowledge about redisplay's inner workings.  Maybe we should simply
> expose to Lisp the corresponding internal variables instead, or
> provide Lisp primitive functions to set them?

I don't mind the current code, but it deserves a comment pointing to the
corresponding part of the C code that is affected.


        Stefan

bug#10539: 24.0.92; low display-time-interval makes Emacs slow

[martin rudalics]

 >> Can you tell me which flag (with-current-buffer (other-buffer)) sets?
 >
 > windows_or_buffers_changed, AFAIR.

(with-current-buffer (other-buffer)) does neither change the contents of
a window nor those of a buffer (unless it recreates *scratch*).

martin

bug#10539: 24.0.92; low display-time-interval makes Emacs slow

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Glenn Morris <rgm@gnu.org>,  michael_heerdegen@web.de,  10539@debbugs.gnu.org
> Date: Sun, 29 Jan 2012 23:40:29 -0500
> 
> > I don't mind, but I'd like Chong's and Stefan's opinion on this first.
> > The way the function is (was) implemented it exploits intimate
> > knowledge about redisplay's inner workings.  Maybe we should simply
> > expose to Lisp the corresponding internal variables instead, or
> > provide Lisp primitive functions to set them?
> 
> I don't mind the current code, but it deserves a comment pointing to the
> corresponding part of the C code that is affected.

The two internal variables in question (update_mode_lines and
windows_or_buffers_changed) affect many parts of the display code, and
also appear in buffer.c, window.c, and a bunch of other files.  Just
grep for them, they are all over the place.

So I'm unsure what you mean by "corresponding part of the C code".

bug#10539: 24.0.92; low display-time-interval makes Emacs slow

[Eli Zaretskii]

> Date: Mon, 30 Jan 2012 11:20:16 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: rgm@gnu.org, michael_heerdegen@web.de, 10539@debbugs.gnu.org
> 
>  >> Can you tell me which flag (with-current-buffer (other-buffer)) sets?
>  >
>  > windows_or_buffers_changed, AFAIR.
> 
> (with-current-buffer (other-buffer)) does neither change the contents of
> a window nor those of a buffer (unless it recreates *scratch*).

Sorry, I don't understand what you are trying to convey.

bug#10539: 24.0.92; low display-time-interval makes Emacs slow

[martin rudalics]

 >>  >> Can you tell me which flag (with-current-buffer (other-buffer)) sets?
 >>  >
 >>  > windows_or_buffers_changed, AFAIR.
 >>
 >> (with-current-buffer (other-buffer)) does neither change the contents of
 >> a window nor those of a buffer (unless it recreates *scratch*).
 >
 > Sorry, I don't understand what you are trying to convey.

If I understand windows_or_buffers_changed correctly, it is only set
when either a window changes (resized, another buffer displayed in it,
...) or a buffer is changed (text inserted, `point' changes, ...).
Neither `with-current-buffer' nor `other-buffer' change a window or a
buffer.  What am I missing?

martin

bug#10539: 24.0.92; low display-time-interval makes Emacs slow

[Eli Zaretskii]

> Date: Mon, 30 Jan 2012 19:13:08 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: rgm@gnu.org, michael_heerdegen@web.de, 10539@debbugs.gnu.org
> 
> Neither `with-current-buffer' nor `other-buffer' change a window or a
> buffer.  What am I missing?

At least at some point they did.  I will have to run Emacs under a
debugger to refresh my faulting memory.

bug#10539: 24.0.92; low display-time-interval makes Emacs slow

[Stefan Monnier]

>> > I don't mind, but I'd like Chong's and Stefan's opinion on this first.
>> > The way the function is (was) implemented it exploits intimate
>> > knowledge about redisplay's inner workings.  Maybe we should simply
>> > expose to Lisp the corresponding internal variables instead, or
>> > provide Lisp primitive functions to set them?
>> I don't mind the current code, but it deserves a comment pointing to the
>> corresponding part of the C code that is affected.
> The two internal variables in question (update_mode_lines and
> windows_or_buffers_changed) affect many parts of the display code, and
> also appear in buffer.c, window.c, and a bunch of other files.  Just
> grep for them, they are all over the place.

Indeed, that's why a comment is needed: the corresponding info is not
easy to find.

> So I'm unsure what you mean by "corresponding part of the C code".

The corresponding parts would be:
1- the place where the C code (run via the Elisp code of
   force-mode-line-update) sets those vars.
2- the place in the C code where those vars are checked later on during
   redisplay so that they cause the mode-line to be refreshed.


        Stefan

bug#10539: 24.0.92; low display-time-interval makes Emacs slow

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: rgm@gnu.org, michael_heerdegen@web.de, 10539@debbugs.gnu.org
> Date: Mon, 30 Jan 2012 17:01:53 -0500
> 
> The corresponding parts would be:
> 1- the place where the C code (run via the Elisp code of
>    force-mode-line-update) sets those vars.
> 2- the place in the C code where those vars are checked later on during
>    redisplay so that they cause the mode-line to be refreshed.

OK, will do.

bug#10539: 24.0.92; low display-time-interval makes Emacs slow

[Lars Ingebrigtsen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> The docstring of `display-time-interval' says "Seconds between updates
> of time in the mode line.".  Ok, fine.  The doc of
> `display-time-string-forms' includes an example which makes
> `display-time-mode' show seconds.  So, the user may think setting
> `display-time-interval' to 1 is a good idea.
>
> But it is currently not, on the contrary.
>
> First of all, `display-time-update' is a long, complex function.
> Running only its calculations every second consumes some percent CPU by
> itself.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

I've tried this in Emacs 29, and the Emacs in question does not show up
on "top" as consuming any CPU, so this has perhaps improved?

> Second, the doc of `display-time-update' says
>
>   Update the display-time info for the mode line.
>   However, don't redisplay right now.
>
> But it _does_ redisplay, it calls `force-mode-line-update' explicitly at
> the end of the code!

As noted in the bug thread, `force-mode-line-update' just sets some
variables to make the next redisplay cycle update the mode lines, so
the doc string is correct, I think.

The discussion then went on to adding some more comments or something,
but I'm not sure whether there's anything more to be done here?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#10539: 24.0.92; low display-time-interval makes Emacs slow

[Michael Heerdegen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I've tried this in Emacs 29, and the Emacs in question does not show
> up on "top" as consuming any CPU, so this has perhaps improved?

Maybe, I dunno. Everything currently looks quite sane here, no problem.

> As noted in the bug thread, `force-mode-line-update' just sets some
> variables to make the next redisplay cycle update the mode lines, so
> the doc string is correct, I think.

Probably right.

> The discussion then went on to adding some more comments or something,
> but I'm not sure whether there's anything more to be done here?

I haven't checked if everyone has committed every suggested aspect of
improvements to the docs.  If nobody else answers, you might close, from
my side.

Thanks,

Michael.

bug#10539: 24.0.92; low display-time-interval makes Emacs slow

[Lars Ingebrigtsen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> I haven't checked if everyone has committed every suggested aspect of
> improvements to the docs.  If nobody else answers, you might close, from
> my side.

OK; closing.  (If somebody else responds and feels there more to be done
here, we'll reopen.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no