bug#29554: 25.3; 100% CPU spinning, while parsing compile output.

bug#29554: 25.3; 100% CPU spinning, while parsing compile output.

[Sam Varshavchik]

[-- Attachment #1: Type: text/plain, Size: 4862 bytes --]

Attached is simple makefile with a bunch of echo statements that reproduce  
the output of an actual compilation. I had to gzip and attach it, in order  
to avoid the large lines getting messed up by E-mail formatting.

Saving this makefile, and hitting F5, or executing "compile" makes emacs  
spin with 100% CPU utilization for about five seconds, before it starts  
responding again. Then, going to the compilation output buffer, and M-> to  
go the end of the buffer, that also pegs emacs for another 4-5 seconds, at  
100% cpu.

Yup, these are very long lines. But that's the end result from automake and  
libtool. This is the real world, when it comes to C++ development these  
days...




In GNU Emacs 25.3.1 (x86_64-redhat-linux-gnu, GTK+ Version 3.22.19)
 of 2017-09-14 built on buildvm-31.phx2.fedoraproject.org
Windowing system distributor 'Fedora Project', version 11.0.11905000
Configured using:
 'configure --build=x86_64-redhat-linux-gnu
 --host=x86_64-redhat-linux-gnu --program-prefix=
 --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr
 --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
 --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64
 --libexecdir=/usr/libexec --localstatedir=/var
 --sharedstatedir=/var/lib --mandir=/usr/share/man
 --infodir=/usr/share/info --with-dbus --with-gif --with-jpeg --with-png
 --with-rsvg --with-tiff --with-xft --with-xpm --with-x-toolkit=gtk3
 --with-gpm=no --with-xwidgets --with-modules
 build_alias=x86_64-redhat-linux-gnu host_alias=x86_64-redhat-linux-gnu
 'CFLAGS=-DMAIL_USE_LOCKF -O2 -g -pipe -Wall -Werror=format-security
 -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong
 --param=ssp-buffer-size=4 -grecord-gcc-switches
 -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic'
 LDFLAGS=-Wl,-z,relro
 PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND DBUS GCONF GSETTINGS NOTIFY
ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 MODULES XWIDGETS

Important settings:
  value of $LANG: en_US.utf8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Compilation

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
Loading /usr/share/emacs/site-lisp/site-start.d/anthy-init.el (source)...done
Loading /usr/share/emacs/site-lisp/site-start.d/autoconf-init.el (source)...done
Loading /usr/share/emacs/site-lisp/site-start.d/desktop-entry-mode-init.el (source)...done
Loading /usr/share/emacs/site-lisp/site-start.d/git-init.el (source)...done
Loading /usr/share/emacs/site-lisp/site-start.d/mercurial-site-start.el (source)...done
Loading /usr/share/emacs/site-lisp/site-start.d/rpm-spec-mode-init.el (source)...done
For information about GNU Emacs and the GNU system, type C-h C-a.
Compilation finished
Mark set
next-line: End of buffer

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message idna dired format-spec rfc822
mml mml-sec password-cache epg epg-config gnus-util mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util help-fns help-mode easymenu
cl-loaddefs pcase cl-lib mail-prsvr mail-utils compile comint ansi-color
ring time-date mule-util tooltip eldoc electric uniquify ediff-hook
vc-hooks lisp-float-type mwheel x-win term/common-win x-dnd tool-bar dnd
fontset image regexp-opt fringe tabulated-list newcomment elisp-mode
lisp-mode prog-mode register page menu-bar rfn-eshadow timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame
cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai
tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian
slovak czech european ethiopic indian cyrillic chinese charscript
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote dbusbind inotify
dynamic-setting system-font-setting font-render-setting xwidget-internal
move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 93448 8431)
 (symbols 48 20589 0)
 (miscs 40 53 146)
 (strings 32 16324 4384)
 (string-bytes 1 479802)
 (vectors 16 12525)
 (vector-slots 8 441765 5250)
 (floats 8 175 46)
 (intervals 56 298 0)
 (buffers 976 19))


[-- Attachment #2: Makefile.gz --]
[-- Type: application/gzip, Size: 4238 bytes --]

bug#29554: 25.3; 100% CPU spinning, while parsing compile output.

[Eli Zaretskii]

> From: Sam Varshavchik <mrsam@courier-mta.com>
> Date: Sun, 03 Dec 2017 12:55:49 -0500
> 
> Attached is simple makefile with a bunch of echo statements that reproduce  
> the output of an actual compilation. I had to gzip and attach it, in order  
> to avoid the large lines getting messed up by E-mail formatting.
> 
> Saving this makefile, and hitting F5, or executing "compile" makes emacs  
> spin with 100% CPU utilization for about five seconds, before it starts  
> responding again. Then, going to the compilation output buffer, and M-> to  
> go the end of the buffer, that also pegs emacs for another 4-5 seconds, at  
> 100% cpu.
> 
> Yup, these are very long lines. But that's the end result from automake and  
> libtool. This is the real world, when it comes to C++ development these  
> days...

Maybe my machine is much faster than yours (although it's a 6-year old
box), but I don't see such long delays, the responses are sub-second
here (something like 0.2 sec or so).  Did you visit the file in
Makefile mode or in some other mode?

bug#29554: 25.3; 100% CPU spinning, while parsing compile output.

[Sam Varshavchik]

Eli Zaretskii writes:

> > From: Sam Varshavchik <mrsam@courier-mta.com>
> > Date: Sun, 03 Dec 2017 12:55:49 -0500
> >
> > Attached is simple makefile with a bunch of echo statements that reproduce
> > the output of an actual compilation. I had to gzip and attach it, in order
> > to avoid the large lines getting messed up by E-mail formatting.
> >
> > Saving this makefile, and hitting F5, or executing "compile" makes emacs
> > spin with 100% CPU utilization for about five seconds, before it starts
> > responding again. Then, going to the compilation output buffer, and M-> to
> > go the end of the buffer, that also pegs emacs for another 4-5 seconds, at
> > 100% cpu.
> >
> > Yup, these are very long lines. But that's the end result from automake and
> > libtool. This is the real world, when it comes to C++ development these
> > days...
>
> Maybe my machine is much faster than yours (although it's a 6-year old
> box), but I don't see such long delays, the responses are sub-second
> here (something like 0.2 sec or so).  Did you visit the file in
> Makefile mode or in some other mode?

It's compile output mode. Save the Makefile. The default F5 binding runs  
the "compile" command, which executes make.

make then processes this makefile, generates the output, and emacs tries to  
parse the output, as output from "make". That's where it spins for me.

bug#29554: 25.3; 100% CPU spinning, while parsing compile output.

[Noam Postavsky]

merge 29554 13369
quit

Sam Varshavchik <mrsam@courier-mta.com> writes:

> Attached is simple makefile with a bunch of echo statements that
> reproduce the output of an actual compilation. I had to gzip and
> attach it, in order to avoid the large lines getting messed up by
> E-mail formatting.
>
> Saving this makefile, and hitting F5, or executing "compile" makes
> emacs spin with 100% CPU utilization for about five seconds, before it
> starts responding again. Then, going to the compilation output buffer,
> and M-> to go the end of the buffer, that also pegs emacs for another
> 4-5 seconds, at 100% cpu.
>
> Yup, these are very long lines. But that's the end result from
> automake and libtool. This is the real world, when it comes to C++
> development these days...

This is Bug#13369/9065/3700.  You can get some relief by pruning
compilation-error-regexp-alist.