GNU bug report logs - #3032
Major performance problem

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 3032 in the body.
You can then email your comments to 3032 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Michael Linck <mgl <at> absolute-performance.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Major performance problem
Date: Fri, 17 Apr 2009 14:31:16 -0600

Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the bug-gnu-emacs <at> gnu.org mailing list,
and to the gnu.emacs.bug news group.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

If you make a C++ header and try to define a long string, you can bring
emacs to a grinding halt.  The scenario is as follows:  I need a test
header to return the equivalent of some lengthy http resources for unit
testing and I can't have file system interaction, so I have to hard code
the scenarios in a variety of header files for the unit tests.  For each
resource, I need a string constant.  So I have to copy the body of the
resource into the cxx header.  Then backslash escape the quotes, then 
replace
newlines with '\n"[newline]"' and then auto indent the buffer.
For a resource that is *merely* 8000 lines (that 8 thousand, not eight
trillion) the simple quote escaping (replace '"' with '\"') takes more than
5-10 minutes, the newlines (no more than 1 per line) takes 5-10 minutes 
also.
This BUG however, is filed because the indentation has now been in progress
for over 3 hours!  It was 37 percent complete an hour ago, now it's 40%
complete.  That emacs instance is using up a entire CPU core, and the 
process
of indenting a bit of code seems to be slowing down hard as it goes.  
37% the
first 2 hours, 3% the following hour.  I expect this *maybe* finish over the
weekend.  I've been using emacs for at least 10 years, and this is shocking.

Another minor gripe is that I tried having emacs send this bug 
previously, but
I had to decide to send it again manually, because it gives no 
indication of
whether the bug e-mail was actually sent or not.  Anyway, in my professional
opinion as a developer, it's time to put a stop to any "feature" updates 
for e-macs
and hunker down with some optimizations. 

emacs version 22.3.1

Thanks, guys.

If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
   `bt full' and `xbacktrace'.
If you would like to further debug the crash, please read the file
/usr/share/emacs/22.3/etc/DEBUG for instructions.


In GNU Emacs 22.3.1 (i386-redhat-linux-gnu, GTK+ Version 2.14.7)
of 2009-02-09 on x86-5.fedora.phx.redhat.com
Windowing system distributor `The X.Org Foundation', version 11.0.10503000
configured using `configure  '--build=i386-redhat-linux-gnu' 
'--host=i386-redhat-linux-gnu' '--target=i386-redhat-linux-gnu' 
'--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' 
'--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' 
'--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' 
'--libexecdir=/usr/libexec' '--localstatedir=/var' 
'--sharedstatedir=/usr/com' '--mandir=/usr/share/man' 
'--infodir=/usr/share/info' '--with-x-toolkit=gtk' 
'build_alias=i386-redhat-linux-gnu' 'host_alias=i386-redhat-linux-gnu' 
'target_alias=i386-redhat-linux-gnu' 'CFLAGS=-DMAIL_USE_LOCKF -O2 -g 
-pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector 
--param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic 
-fasynchronous-unwind-tables''

Important settings:
 value of $LC_ALL: nil
 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: nil
 value of $LANG: en_US.UTF-8
 locale-coding-system: utf-8
 default-enable-multibyte-characters: t

Major mode: C/lh

Minor modes in effect:
 tooltip-mode: t
 tool-bar-mode: t
 mouse-wheel-mode: t
 menu-bar-mode: t
 file-name-shadow-mode: t
 global-font-lock-mode: t
 font-lock-mode: t
 blink-cursor-mode: t
 unify-8859-on-encoding-mode: t
 utf-translate-cjk-mode: t
 auto-compression-mode: t
 column-number-mode: t
 line-number-mode: t
 transient-mark-mode: identity
 abbrev-mode: t

Recent input:
<left> <left> <left> <left> <left> <left> <left> <left>
<left> <left> <left> <left> <left> <left> <left> <left>
<left> <left> <left> <left> <left> <left> <left> <left>
<left> <left> <left> <return> <delete> <end> <delete>
SPC <end> <left> <up> <down-mouse-1> <mouse-1> <tab>
<return> <delete> <end> <delete> SPC <right> <right>
<right> <right> <right> <C-right> <C-right> <C-right>
<C-right> <C-right> <return> <tab> <backspace> <backspace>
<backspace> <backspace> <backspace> <delete> <end>
<delete> SPC <C-right> <C-right> <C-right> <C-right>
<C-right> <C-right> <return> <tab> <backspace> <backspace>
<backspace> <backspace> <backspace> <backspace> <backspace>
<backspace> <delete> <end> <delete> SPC <C-right> <C-right>
<C-right> <C-right> <C-right> <C-right> <C-right> <return>
<delete> <end> <delete> SPC <C-right> <C-right> <C-right>
<C-right> <C-right> <C-right> <C-right> <return> <delete>
<end> <delete> SPC <C-right> <C-right> <C-right> <C-right>
<C-right> <C-right> <C-right> <return> <delete> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <down-mouse-1> <mouse-1> <return>
e m a c s SPC v e r s i o n SPC i s SPC 2 2 . 3 . 1
<backspace> 1 <help-echo> <down-mouse-1> <mouse-1>
<escape> <escape> <escape> <help-echo> <help-echo>
<down-mouse-5> <mouse-5> <double-down-mouse-5> <double-mouse-5>
<down-mouse-4> <mouse-4> <double-down-mouse-4> <double-mouse-4>
<triple-down-mouse-4> <triple-mouse-4> <down-mouse-4>
<mouse-4> <double-down-mouse-4> <double-mouse-4> <down-mouse-5>
<mouse-5> <double-down-mouse-5> <double-mouse-5> <triple-down-mouse-5>
<triple-mouse-5> <down-mouse-5> <mouse-5> <double-down-mouse-5>
<double-mouse-5> <triple-down-mouse-5> <triple-mouse-5>
<down-mouse-5> <mouse-5> <double-down-mouse-5> <double-mouse-5>
<triple-down-mouse-5> <triple-mouse-5> <down-mouse-4>
<mouse-4> <double-down-mouse-4> <double-mouse-4> <triple-down-mouse-4>
<triple-mouse-4> <triple-down-mouse-4> <triple-mouse-4>
<down-mouse-4> <mouse-4> <double-down-mouse-4> <double-mouse-4>
<triple-down-mouse-4> <triple-mouse-4> <triple-down-mouse-4>
<triple-mouse-4> <triple-down-mouse-4> <triple-mouse-4>
<triple-down-mouse-4> <triple-mouse-4> <triple-down-mouse-4>
<triple-mouse-4> <triple-down-mouse-4> <triple-mouse-4>
<help-echo> <help-echo> <help-echo> <help-echo> <down-mouse-1>
<mouse-1> C-c C-c y e s <return> <help-echo> <help-echo>
<down-mouse-1> <mouse-1> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <down-mouse-1>
<mouse-1> <help-echo> <down-mouse-1> <mouse-1> <help-echo>
<down-mouse-1> <mouse-1> <down-mouse-4> <mouse-4> <double-down-mouse-4>
<double-mouse-4> <triple-down-mouse-4> <triple-mouse-4>
<down-mouse-5> <mouse-5> <double-down-mouse-5> <double-mouse-5>
<down-mouse-5> <mouse-5> <down-mouse-5> <mouse-5> <double-down-mouse-5>
<double-mouse-5> <down-mouse-4> <mouse-4> <down-mouse-1>
<mouse-1> <down-mouse-1> <mouse-1> M-x r e p o r t
- e m a b <backspace> c s - b u g <return>

Recent messages:
Auto-saving...done
Auto-saving...done
Auto-saving...done
Auto-saving...done
Auto-saving...done
Auto-saving...done
Auto-saving...done
Auto-saving...done
byte-code: Beginning of buffer [7 times]
Sending...done

Message #10 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Michael Linck <mgl <at> absolute-performance.com>,
        3032 <at> debbugs.gnu.org
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#3032: Major performance problem
Date: Fri, 17 Apr 2009 23:08:10 +0000

Hi, Michael!

On Fri, Apr 17, 2009 at 02:31:16PM -0600, Michael Linck wrote:

> If you make a C++ header and try to define a long string, you can bring
> emacs to a grinding halt.  The scenario is as follows:  I need a test
> header to return the equivalent of some lengthy http resources for unit
> testing and I can't have file system interaction, so I have to hard
> code the scenarios in a variety of header files for the unit tests.
> For each resource, I need a string constant.  So I have to copy the
> body of the resource into the cxx header.

Could you perhaps describe this in more concrete terms, since I not quite
sure what you mean by an "http resource" - Maybe show me the top few
lines and the bottom few lines of what you're copying into the C
file.....

> Then backslash escape the quotes, then replace newlines with
> '\n"[newline]"' and then auto indent the buffer.  For a resource that
> is *merely* 8000 lines (that 8 thousand, not eight trillion) the simple
> quote escaping (replace '"' with '\"') takes more than 5-10 minutes,
> the newlines (no more than 1 per line) takes 5-10 minutes also.

....., and then please tell me exactly what keys you type to do this
replacement.

> This BUG however, is filed because the indentation has now been in
> progress for over 3 hours!  It was 37 percent complete an hour ago, now
> it's 40% complete.  That emacs instance is using up a entire CPU core,
> and the process of indenting a bit of code seems to be slowing down
> hard as it goes.  37% the first 2 hours, 3% the following hour.  I
> expect this *maybe* finish over the weekend.  I've been using emacs for
> at least 10 years, and this is shocking.

Yes, I agree.  Sorry!  I'm working on a bug at the moment which might
actually have the same root as the bug you've tripped over: it happens
when there's what I call a "brace dessert", a large section of text
without any '{'s or '}'s.  I'm reworking the relevant mechanism at the
moment, but it's quite a big job.

<OPTIONAL BIT, if you're interested in the Emacs internals>
CC Mode caches structural information about brace positions, and when the
changes are made to the source or even when the current position changes,
it updates this cache.  Sadly, at the moment, it scans backwards to the
previous brace position each time.  For typical code, this is fast
enough, but in a brace dessert, it scans back to the beginning of the
buffer each time, which is a performance disaster.
</OPTIONAL BIT>

> Another minor gripe is that I tried having emacs send this bug
> previously, but I had to decide to send it again manually, because it
> gives no indication of whether the bug e-mail was actually sent or not.

That bit's not my department, sorry.

> Anyway, in my professional opinion as a developer, it's time to put a
> stop to any "feature" updates for e-macs and hunker down with some
> optimizations. 

We do what we can.  :-)  But please keep on sending in bug reports
whenever you see a problem like this.  It's not like there is any general
optimisation that we need to get around to.  Rather, there are certain
"strange" types of source file, certain "strange" syntaxes which trigger
specific problems or show up bad assumptions that we've made in the past.

C is a horrendously complicated language in an editor.  C++ is an order
of magnitude worse, and in fact it has constructs which cannot be parsed
unambiguously without a full blown compiler.  So awkward "little" things
keep cropping up, things we haven't thought about, year after year.  We
knock them down, one by one.  ;-(

> emacs version 22.3.1

Any chance you could send me a CC Mode configuration dump, too?  Go to
that buffer and type C-c C-b.  Then cut and paste as appropriate into
your email.  And could you please try starting emacs as "emacs -Q", just
to make sure there's nothing in your init file causing the problem
(though I'm pretty sure there isn't).

As a temporary workaround, it might help to switch to a different mode
(M-x fundamental-mode) do the 8000 line edit, then switch back to C Mode
(M-x c-mode).

> Thanks, guys.

That's OK!  Thanks for taking the trouble to report the bug.

-- 
Alan Mackenzie (Nuremberg, Germany).

Previous Next

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