GNU bug report logs - #29554
25.3; 100% CPU spinning, while parsing compile output.

Previous Next

Full log

View this message in rfc822 format

From: Sam Varshavchik <mrsam <at> courier-mta.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 29554 <at> debbugs.gnu.org
Subject: bug#29554: 25.3; 100% CPU spinning, while parsing compile output.
Date: Mon, 04 Dec 2017 14:38:57 -0500

Eli Zaretskii writes:

> > From: Sam Varshavchik <mrsam <at> 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.

Previous Next

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