From unknown Sat Sep 06 11:42:06 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#3032 <3032@debbugs.gnu.org> To: bug#3032 <3032@debbugs.gnu.org> Subject: Status: Major performance problem Reply-To: bug#3032 <3032@debbugs.gnu.org> Date: Sat, 06 Sep 2025 18:42:06 +0000 retitle 3032 Major performance problem reassign 3032 emacs,cc-mode submitter 3032 Michael Linck severity 3032 normal thanks From mgl@absolute-performance.com Fri Apr 17 13:31:37 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 17 Apr 2009 20:31:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=0.1 required=4.0 tests=FOURLA autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n3HKVWgm001580 for ; Fri, 17 Apr 2009 13:31:34 -0700 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Luuii-0000Gl-8s for bug-gnu-emacs@gnu.org; Fri, 17 Apr 2009 16:31:32 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Luuic-0000Fc-86 for bug-gnu-emacs@gnu.org; Fri, 17 Apr 2009 16:31:30 -0400 Received: from [199.232.76.173] (port=45821 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Luuic-0000FZ-2j for bug-gnu-emacs@gnu.org; Fri, 17 Apr 2009 16:31:26 -0400 Received: from mx02.den.sysshep.com ([66.35.32.228]:54022 helo=fort-mx02.den.api.local) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Luuib-0003TE-JV for bug-gnu-emacs@gnu.org; Fri, 17 Apr 2009 16:31:25 -0400 Received: from mike-desktop.boulder.api.local ([64.15.110.115]) (authenticated bits=0) by fort-mx02.den.api.local (8.13.1/8.13.1) with ESMTP id n3HKVG73008602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 17 Apr 2009 14:31:21 -0600 Message-ID: <49E8E714.2070605@absolute-performance.com> Date: Fri, 17 Apr 2009 14:31:16 -0600 From: Michael Linck User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: bug-gnu-emacs@gnu.org Subject: Major performance problem Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) 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@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: SPC SPC SPC SPC SPC SPC e m a c s SPC v e r s i o n SPC i s SPC 2 2 . 3 . 1 1 C-c C-c y e s M-x r e p o r t - e m a b c s - b u g 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 From acm@muc.de Fri Apr 17 16:08:23 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 17 Apr 2009 23:08:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.0 required=4.0 tests=HAS_BUG_NUMBER autolearn=unavailable version=3.2.5-bugs.debian.org_2005_01_02 Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n3HN8KYT014217 for ; Fri, 17 Apr 2009 16:08:21 -0700 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LuxAR-0002N0-NU for bug-gnu-emacs@gnu.org; Fri, 17 Apr 2009 19:08:19 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LuxAN-0002Jf-2q for bug-gnu-emacs@gnu.org; Fri, 17 Apr 2009 19:08:19 -0400 Received: from [199.232.76.173] (port=40102 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LuxAM-0002JX-OI for bug-gnu-emacs@gnu.org; Fri, 17 Apr 2009 19:08:14 -0400 Received: from colin.muc.de ([193.149.48.1]:1754 helo=mail.muc.de) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LuxAM-0001zi-40 for bug-gnu-emacs@gnu.org; Fri, 17 Apr 2009 19:08:14 -0400 Received: (qmail 50707 invoked by uid 3782); 17 Apr 2009 23:08:12 -0000 Received: from acm.muc.de (pD9E23450.dip.t-dialin.net [217.226.52.80]) by colin2.muc.de (tmda-ofmipd) with ESMTP; Sat, 18 Apr 2009 01:08:10 +0200 Received: (qmail 14376 invoked by uid 1000); 17 Apr 2009 23:08:10 -0000 Date: Fri, 17 Apr 2009 23:08:10 +0000 To: Michael Linck , 3032@debbugs.gnu.org Cc: bug-gnu-emacs@gnu.org Subject: Re: bug#3032: Major performance problem Message-ID: <20090417230810.GA13813@muc.de> References: <49E8E714.2070605@absolute-performance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49E8E714.2070605@absolute-performance.com> User-Agent: Mutt/1.5.9i X-Delivery-Agent: TMDA/1.1.5 (Fettercairn) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-detected-operating-system: by monty-python.gnu.org: FreeBSD 4.6-4.9 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. 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. > 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). From rgm@gnu.org Fri Apr 17 17:01:41 2009 Received: (at control) by emacsbugs.donarmstrong.com; 18 Apr 2009 00:01:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.0 required=4.0 tests=VALID_BTS_CONTROL autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n3I01cpO029398 for ; Fri, 17 Apr 2009 17:01:39 -0700 Received: from rgm by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1Luy00-0005G5-EJ; Fri, 17 Apr 2009 20:01:37 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18921.6240.334314.149658@fencepost.gnu.org> Date: Fri, 17 Apr 2009 20:01:36 -0400 From: Glenn Morris To: control Subject: control message severity 2988 minor reassign 3005 emacs,w32 tags 3012 moreinfo unreproducible severity 3016 wishlist reassign 3021 emacs,w32 reassign 3019 spam reassign 3023 spam reassign 3024 spam reassign 3025 spam reassign 3026 spam reassign 3028 spam reassign 3029 spam reassign 3030 spam reassign 3031 spam reassign 3032 emacs,cc-mode reassign 3034 spam reassign 3039 emacs,ns reassign 3040 emacs,ns reassign 3041 spam From debbugs-submit-bounces@debbugs.gnu.org Thu Jun 24 14:23:37 2010 Received: (at control) by debbugs.gnu.org; 24 Jun 2010 18:23:37 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ORr5N-00051L-8v for submit@debbugs.gnu.org; Thu, 24 Jun 2010 14:23:37 -0400 Received: from pantheon-po41.its.yale.edu ([130.132.50.98]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ORr5K-00051G-K0 for control@debbugs.gnu.org; Thu, 24 Jun 2010 14:23:35 -0400 Received: from furry (dhcp128036014221.central.yale.edu [128.36.14.221]) (authenticated bits=0) by pantheon-po41.its.yale.edu (8.12.11.20060308/8.12.11) with ESMTP id o5OINUI2013527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 24 Jun 2010 14:23:30 -0400 Received: by furry (Postfix, from userid 1000) id 5BF4B16D416; Thu, 24 Jun 2010 20:23:29 +0200 (CEST) From: Chong Yidong To: control@debbugs.gnu.org Subject: close 1382 Date: Thu, 24 Jun 2010 14:23:29 -0400 Message-ID: <87r5jw5ly6.fsf@stupidchicken.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-YaleITSMailFilter: Version 1.2c (attachment(s) not renamed) X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.7 (--) severity 135 minor tags 710 + moreinfo unreproducible close 756 tags 844 + moreinfo unreproducible close 917 close 1000 tags 1125 + moreinfo unreproducible close 1159 severity 1238 wishlist close 1247 close 1381 close 1382 tags 1708 + moreinfo unreproducible close 1993 severity 2024 wishlist close 2236 severity 2299 wishlist tags 2394 + moreinfo unreproducible severity 2507 minor close 2583 tags 2690 + moreinfo unreproducible tags 2812 + moreinfo unreproducible tags 2843 + moreinfo unreproducible tags 2870 + moreinfo unreproducible tags 2877 + moreinfo unreproducible close 3032 close 3273 close 3349 close 4046 close 4358 close 4591 close 4656 thanks From unknown Sat Sep 06 11:42:06 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Fri, 23 Jul 2010 11:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator