From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.cc-mode.general,gmane.emacs.devel Subject: Re: Unbearably slow editing in .h files Date: Sun, 24 Feb 2008 09:55:23 +0100 Message-ID: <47C130FB.5000209@gmx.at> References: <8763xl492o.fsf@jurta.org> <200801230225.m0N2Ptmx012952@sallyv1.ics.uci.edu> <200801271954.m0RJsmBm003714@sallyv1.ics.uci.edu> <479DAC55.8070302@gmx.at> <200801300258.m0U2w9rr005169@sallyv1.ics.uci.edu> <47B9E0B1.1090908@gmx.at> <20080223224901.GB3476@muc.de> <47C0A376.8080105@gmx.at> <20080223232552.GC3476@muc.de> 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 1203845069 20425 80.91.229.12 (24 Feb 2008 09:24:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 24 Feb 2008 09:24:29 +0000 (UTC) Cc: bug-cc-mode@gnu.org, Stefan Monnier , emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: cc-mode-help-bounces@lists.sourceforge.net Sun Feb 24 10:24:53 2008 Return-path: Envelope-to: sf-cc-mode-help@m.gmane.org Original-Received: from lists-outbound.sourceforge.net ([66.35.250.225]) by lo.gmane.org with esmtp (Exim 4.50) id 1JTD6L-0000K5-1K for sf-cc-mode-help@m.gmane.org; Sun, 24 Feb 2008 10:24:53 +0100 Original-Received: from sc8-sf-list1-new.sourceforge.net (sc8-sf-list1-new-b.sourceforge.net [10.3.1.93]) by sc8-sf-spam2.sourceforge.net (Postfix) with ESMTP id 4E41BF851; Sun, 24 Feb 2008 01:24:21 -0800 (PST) Original-Received: from sc8-sf-mx2-b.sourceforge.net ([10.3.1.92] helo=mail.sourceforge.net) by sc8-sf-list1-new.sourceforge.net with esmtp (Exim 4.43) id 1JTD5n-00054V-Ke for cc-mode-help@lists.sourceforge.net; Sun, 24 Feb 2008 01:24:19 -0800 Original-Received: from fencepost.gnu.org ([140.186.70.10]) by mail.sourceforge.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44) id 1JTD5m-0002Dj-4R for cc-mode-help@lists.sourceforge.net; Sun, 24 Feb 2008 01:24:19 -0800 Original-Received: from mx10.gnu.org ([199.232.76.166]) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1JTD5j-0004Za-6A for bug-cc-mode@gnu.org; Sun, 24 Feb 2008 04:24:15 -0500 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1JTD5g-0006x3-2M for bug-cc-mode@gnu.org; Sun, 24 Feb 2008 04:24:15 -0500 Original-Received: from mail.gmx.net ([213.165.64.20]) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1JTD5f-0006wk-Jm for bug-cc-mode@gnu.org; Sun, 24 Feb 2008 04:24:11 -0500 Original-Received: (qmail invoked by alias); 24 Feb 2008 08:57:30 -0000 Original-Received: from N715P031.adsl.highway.telekom.at (EHLO [62.47.33.95]) [62.47.33.95] by mail.gmx.net (mp008) with SMTP; 24 Feb 2008 09:57:30 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+DQxQLIbuDa8utD2F18qVtmK9iSvVucx6ffaQ5gN ofgu25E0egjIg0 User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: de-DE, de, en-us, en In-Reply-To: <20080223232552.GC3476@muc.de> X-Y-GMX-Trusted: 0 X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 3) X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by sourceforge.net. See http://spamassassin.org/tag/ for more details. Report problems to http://sf.net/tracker/?func=add&group_id=1&atid=200001 X-BeenThere: cc-mode-help@lists.sourceforge.net X-Mailman-Version: 2.1.8 Precedence: list List-Id: "Bug reports, feature requests, and general talk about CC Mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: cc-mode-help-bounces@lists.sourceforge.net Errors-To: cc-mode-help-bounces@lists.sourceforge.net Xref: news.gmane.org gmane.emacs.cc-mode.general:5092 gmane.emacs.devel:90209 Archived-At: > Yes, very. Sadly. It takes about 18 seconds for me (1.2 GHz Athlon). > However, it is having to analyze over 54kBytes of C source between EOB > and EO-last-defun. This time is taken up almost fully by the call to > c-where-wrt-to-brace-construct. Maybe this could be optimised. Maybe, > on the other hand, it's not reasonable to expect anything faster in this > pathological case. I think `c-beginning-of-defun' should also report an error within reasonable time when defuns are malformed. How about providing some `c-fast-beginning-of-defun' mechanism which might not be able to cater with all possible ways to write a defun but is reasonably fast for well-written ones? > By comparison, if you do the same in lread.c, it takes much less than a > second. It may be that the plethora of macros in lisp.h is causing the > delay. The plain idea of potentially scanning the entire buffer backwards is tantalizing. There should be some way to avoid that. > However, there are two problems conflated in this thread. There's the > slowness in certain C files, and there's the way C-x 4 a calls > c-\(beginning\|end\)-of-defun five times. Lets separate them! > > 5 x 18s = 1.5 minutes. This is the other thing that is slugging C-x 4 a. > add-log-current-defun is _emulating_ c-where-wrt-to-brace-construct, and > emulations tend to be slow. ;-) Sure. I already mentioned in this thread that I fail to understand how `add-log-current-defun' is organized. The problem is: Changing that function may implicitly alter the way change logs entries get written. This could go on - for some time - unnoticed and lead to considerable confusions afterwards. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/