From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.cc-mode.general,gmane.emacs.devel Subject: Re: open large file with C code: is it realy should be so slow? Date: Sun, 4 Jan 2009 23:31:14 +0000 Message-ID: <20090104233114.GA11962@muc.de> References: <2a382c6e0812010201h7a2507fbg66a38f392d9837a9@mail.gmail.com> <20081201123716.GA3603@muc.de> <2a382c6e0901041407w2ca824cdy88d1529af8966069@mail.gmail.com> Reply-To: bug-cc-mode@gnu.org NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1231110906 9501 80.91.229.12 (4 Jan 2009 23:15:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 4 Jan 2009 23:15:06 +0000 (UTC) Cc: bug-cc-mode@gnu.org, emacs-devel@gnu.org To: Dave Milter Original-X-From: cc-mode-help-bounces@lists.sourceforge.net Mon Jan 05 00:16:17 2009 Return-path: Envelope-to: sf-cc-mode-help@m.gmane.org Original-Received: from lists.sourceforge.net ([216.34.181.88]) by lo.gmane.org with esmtp (Exim 4.50) id 1LJcCe-0007rL-JO for sf-cc-mode-help@m.gmane.org; Mon, 05 Jan 2009 00:16:17 +0100 Original-Received: from localhost ([127.0.0.1] helo=sfs-ml-1.v29.ch3.sourceforge.com) by 235xhf1.ch3.sourceforge.com with esmtp (Exim 4.69) (envelope-from ) id 1LJcBM-00028v-71; Sun, 04 Jan 2009 23:14:56 +0000 Original-Received: from sfi-mx-4.v28.ch3.sourceforge.com ([172.29.28.124] helo=mx.sourceforge.net) by 235xhf1.ch3.sourceforge.com with esmtp (Exim 4.69) (envelope-from ) id 1LJcBK-00028k-U9 for cc-mode-help@lists.sourceforge.net; Sun, 04 Jan 2009 23:14:54 +0000 Received-SPF: neutral (1b2kzd1.ch3.sourceforge.com: 140.186.70.10 is neither permitted nor denied by domain of muc.de) client-ip=140.186.70.10; envelope-from=acm@muc.de; helo=fencepost.gnu.org; Original-Received: from fencepost.gnu.org ([140.186.70.10]) by 1b2kzd1.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) id 1LJcBF-0000dR-KE for cc-mode-help@lists.sourceforge.net; Sun, 04 Jan 2009 23:14:55 +0000 Original-Received: from mx10.gnu.org ([199.232.76.166]:51191) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1LJcA4-0000l2-AY for bug-cc-mode@gnu.org; Sun, 04 Jan 2009 18:13:36 -0500 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1LJcB7-0005Ef-Gi for bug-cc-mode@gnu.org; Sun, 04 Jan 2009 18:14:43 -0500 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on monty-python X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SPF_PASS autolearn=ham version=3.1.0 Original-Received: from colin.muc.de ([193.149.48.1]:4698 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 1LJcB6-0005EJ-RM for bug-cc-mode@gnu.org; Sun, 04 Jan 2009 18:14:41 -0500 Original-Received: (qmail 82560 invoked by uid 3782); 4 Jan 2009 23:14:35 -0000 Original-Received: from acm.muc.de (pD9E50ACC.dip.t-dialin.net [217.229.10.204]) by colin2.muc.de (tmda-ofmipd) with ESMTP; Mon, 05 Jan 2009 00:14:33 +0100 Original-Received: (qmail 12207 invoked by uid 1000); 4 Jan 2009 23:31:14 -0000 Content-Disposition: inline In-Reply-To: <2a382c6e0901041407w2ca824cdy88d1529af8966069@mail.gmail.com> User-Agent: Mutt/1.5.9i X-Delivery-Agent: TMDA/1.1.5 (Fettercairn) X-Primary-Address: acm@muc.de X-detected-operating-system: by monty-python.gnu.org: FreeBSD 4.6-4.9 X-Spam-Score: -2.8 (--) X-Spam-Report: Spam detection software, running on the system "g92kzd1.ch3.sourceforge.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Hi, Dave, I'm actually working on this bug at the moment. With the Yuletide break, and so on, I've kind of lost the thread a bit and I got bogged down in the complexities of the code. I should have got back to you sooner; sorry! [...] Content analysis details: (-2.8 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -4.0 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/, medium trust [140.186.70.10 listed in list.dnswl.org] 1.2 SPF_NEUTRAL SPF: sender does not match SPF record (neutral) X-Headers-End: 1LJcBF-0000dR-KE X-BeenThere: cc-mode-help@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Bug reports, feature requests, and general talk about CC Mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: cc-mode-help-bounces@lists.sourceforge.net Xref: news.gmane.org gmane.emacs.cc-mode.general:5273 gmane.emacs.devel:107583 Archived-At: Hi, Dave, I'm actually working on this bug at the moment. With the Yuletide break, and so on, I've kind of lost the thread a bit and I got bogged down in the complexities of the code. I should have got back to you sooner; sorry! On Mon, Jan 05, 2009 at 01:07:18AM +0300, Dave Milter wrote: > On Mon, Dec 1, 2008 at 3:37 PM, Alan Mackenzie wrote: > > On Mon, Dec 01, 2008 at 01:01:08PM +0300, Dave Milter wrote: > >> I have problem with emacs responsibility, > >> I work with large enough C header files, > >> and when I want to scroll it using mouse's wheel or > >> page (up|down) keys emacs stop react on any keys, like (ctrl+g), > >> and eats 100% of CPU's time during long period, > >> I wonder is this a bug, or expected behaviour? > > It's a bug. > > Although C Mode works "properly" here, it doesn't seem to be tuned > > very well for files like this one (At91SAM9253_inc.h), which contain > > a lot of #defines and comments and nothing else. > I made some more testing (to find out problem in "file", or in "large"), > because of really want to see this bug fixed, It will be fixed, hopefully within the next few days. It's too serious a bug not to fix. > I see the same behaviour on file created by > for ((i=0;i<500;++i)); do echo "extern void f${i}(int a${i});"; done Yes. The CC Mode function which is to blame is `c-parse-state'. It maintains a "cache" of (essentially) brace pairs, using the positions of these braces to scan from. In a "brace desert", it scans from the beginning of the buffer, sometimes many times per (scroll) command, and this is why it is so slow. To see this, create an alternative file like this: for ((i=0;i<500;++i)); do echo "extern void f${i}(int a${i}) {}"; done ^^ Scrolling in this file will be instantaneous, as it should be. > emacs from cvs and emacs 22 show the same behaviour - > eating 100% of cpu, if make fast scrolling. Yes. [ .... ] > In fact, with small files, for example the same script but 5000 -> 500, > I see the same situation, but after eating cpu during some period, > it never eating it after, and all works smoothly, > while with big files it eats it every fast scroll. If you profile the stuff in cc-engine.el, you'll see c-parse-state right at the top. -- Alan Mackenzie (Nuremberg, Germany). ------------------------------------------------------------------------------