From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Unbearably slow editing in .h files Date: Thu, 3 Apr 2008 14:17:03 +0000 Message-ID: <20080403141703.GB1937@muc.de> References: <479DAC55.8070302@gmx.at> <200801300258.m0U2w9rr005169@sallyv1.ics.uci.edu> <47B9E0B1.1090908@gmx.at> <20080223224901.GB3476@muc.de> <47C0A376.8080105@gmx.at> <20080402220710.GC1283@muc.de> <200804022347.m32NlqS5010556@sallyv1.ics.uci.edu> <20080403091400.GA1937@muc.de> <200804031310.m33DAfB3009774@sallyv1.ics.uci.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1207231371 9115 80.91.229.12 (3 Apr 2008 14:02:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 3 Apr 2008 14:02:51 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dan Nicolaescu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Apr 03 16:03:23 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JhQ1K-0004mj-3S for ged-emacs-devel@m.gmane.org; Thu, 03 Apr 2008 16:02:26 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JhQ0h-0005kZ-I0 for ged-emacs-devel@m.gmane.org; Thu, 03 Apr 2008 10:01:47 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JhQ0E-0005cs-GH for emacs-devel@gnu.org; Thu, 03 Apr 2008 10:01:18 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JhQ07-0005Zb-Da for emacs-devel@gnu.org; Thu, 03 Apr 2008 10:01:13 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JhQ05-0005Yy-6R for emacs-devel@gnu.org; Thu, 03 Apr 2008 10:01:09 -0400 Original-Received: from colin.muc.de ([193.149.48.1] 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 1JhQ04-0000AA-BZ for emacs-devel@gnu.org; Thu, 03 Apr 2008 10:01:08 -0400 Original-Received: (qmail 91442 invoked by uid 3782); 3 Apr 2008 14:01:05 -0000 Original-Received: from acm.muc.de (p57AF6627.dip.t-dialin.net [87.175.102.39]) by colin2.muc.de (tmda-ofmipd) with ESMTP; Thu, 03 Apr 2008 16:01:03 +0200 Original-Received: (qmail 6674 invoked by uid 1000); 3 Apr 2008 14:17:03 -0000 Content-Disposition: inline In-Reply-To: <200804031310.m33DAfB3009774@sallyv1.ics.uci.edu> User-Agent: Mutt/1.5.9i X-Delivery-Agent: TMDA/1.1.5 (Fettercairn) X-Primary-Address: acm@muc.de X-detected-kernel: by monty-python.gnu.org: FreeBSD 4.6-4.9 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:94260 Archived-At: Hi, Dan! On Thu, Apr 03, 2008 at 06:10:40AM -0700, Dan Nicolaescu wrote: > Alan Mackenzie writes: > > On Wed, Apr 02, 2008 at 04:47:52PM -0700, Dan Nicolaescu wrote: > > > Alan Mackenzie writes: > > > > I have just fixed this problem (I hope!) in both the Emacs-22 > > > > branch and the trunk. Basically, the contorted functionality > > > > in add-log.el has been superseded by optimised routines in > > > > cc-cmds.el. > > > > On my 1.2 GHz Athlon machine, C-x 4 a now takes around 4 > > > > seconds at the end of lisp.h, in the trunk. It's somewhat > > > > faster in the Emacs-22 branch, but I don't know why. > > > > I think this is fast enough. > > > Can it be faster? Might sound like a joke, but it's a serious > > > question. > > Just to clarify, that 4 seconds is in the extreme case (lisp.h) > > that brought the problem to light. In a typical case, the action > > is "instantaneous". When finding (or failing to find) a function > > name, the new implementation is more than an order of magnitude > > faster than the old. For a macro name, it takes about as long as > > the old. > > > `diff-add-change-log-entries-other-window' uses this (calls it > > > once per diff hunk), and it is nice to let it run on largish diff > > > buffers to quickly produce a skeleton for a ChangeLog . > > Hey, I didn't know you could do this. Thanks for telling me! :-) > > (Actually, until I looked at this bug report, I didn't realise you > > could do C-x 4 a in an elisp or C file - I thought it would only > > work when done in ChangeLog itself.) > Note that `diff-add-change-log-entries-other-window' is C-x 4 A not > C-x 4 a, it is the equivalent of: > FOR each hunk in a diff DO > C-x 4 a Wow! I've just tried this. It's amazing! There are one or two things in it which aren't quite right, though. > When used on a diff buffer with thousands of lines, it is a bit slow. Hmmm. I've only tried it on diffs with elisp files. That was a little slow. Do you mean it's _very_ slow with C file diffs? Can you give some numbers here? Processor speed, size of diff file, time it takes. But then again, people are only going to be using it once or twice per patch (and then having to fill out the result by hand), so it is surely not that critical. But if it were taking 20 minutes rather than 45 seconds, that would be too slow, I agree. > > > Is the slowdown still caused by the fact that is hard to distinguish a > > > K&R functions from variable declarations? > > Again, it's a massive speedup, not a slowdown. Isn't it? > Sorry, I was referring to the fact slowdown cause by K&R checks, not > your patch. I'd be very interested to here how much faster C-x 4 A has become as a result of this patch and my patch on Friday 2008-03-07 to cc-engine.el. > > To the extent that it's still slower than it might be, yes it's the > > K&R stuff making it slow. The function which takes time is > > c-in-knr-argdecl (cc-engine.el, ~L6317). Actually, this function > > gets called twice. It would take a lot of refactoring to make it > > get called only once. > What if it's not called at all? After all, the vast majority of the > users never edit K&R. Just a thought... Well, one set of users who still use K&R is the Emacs development team. ;-) It would be possible, and very easy, to make K&R a user option. But I don't think that's the right thing to do. The overhead that K&R imposes on C-M-a and C-x 4 a is not _that_ high, and it will diminish as processors continue to get faster. I recently put in a hard-coded limit to the number of parameter declarations in a K&R section. That limit is currently 20. -- Alan Mackenzie (Nuremberg, Germany).