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: [acm@muc.de: Re: Emacs 22.2 release plans - request for a slight delay.] Date: Mon, 17 Mar 2008 09:04:49 +0000 Message-ID: <20080317090449.GA2100@muc.de> References: <20080307072737.GA1334@muc.de> <47DD2A9C.70008@gmx.at> <20080316193633.GC1544@muc.de> <47DE1EB9.6070707@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1205743856 5175 80.91.229.12 (17 Mar 2008 08:50:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 17 Mar 2008 08:50:56 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 17 09:51:24 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 1JbB3g-00059y-Tt for ged-emacs-devel@m.gmane.org; Mon, 17 Mar 2008 09:51:05 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JbB37-00076A-Cf for ged-emacs-devel@m.gmane.org; Mon, 17 Mar 2008 04:50:29 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JbB31-00075C-Kw for emacs-devel@gnu.org; Mon, 17 Mar 2008 04:50:23 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JbB2y-000749-Vy for emacs-devel@gnu.org; Mon, 17 Mar 2008 04:50:23 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JbB2y-000742-Ot for emacs-devel@gnu.org; Mon, 17 Mar 2008 04:50:20 -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 1JbB2y-0002bG-5z for emacs-devel@gnu.org; Mon, 17 Mar 2008 04:50:20 -0400 Original-Received: (qmail 10999 invoked by uid 3782); 17 Mar 2008 08:50:17 -0000 Original-Received: from acm.muc.de (p57AF4742.dip.t-dialin.net [87.175.71.66]) by colin2.muc.de (tmda-ofmipd) with ESMTP; Mon, 17 Mar 2008 09:50:14 +0100 Original-Received: (qmail 2281 invoked by uid 1000); 17 Mar 2008 09:04:49 -0000 Content-Disposition: inline In-Reply-To: <47DE1EB9.6070707@gmx.at> 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:92809 Archived-At: Guten Morgen, Martin! On Mon, Mar 17, 2008 at 08:33:13AM +0100, martin rudalics wrote: > > For me (1.2 Ghz Athlon) C-M-a from EOB in .../src/lisp.h take ~1.5 > > seconds. Previously, it was about 30 seconds. That's an order of > > magnitude speed up. > I appreciate that. The problem is that `add-change-log-entry' here > still spends some 7 secs not finding anything useful with `point' on > the line reading > extern Lisp_Object safe_alloca_unwind (Lisp_Object); > admittedly also because `add-change-log-entry' is rather stupid. It calls c-beginning-of-defun 5(?) times whilst locating the name of the current defun. It does this because it has to jockey about, feeling out whether it started _inside_ the function block, somewhere in the function's header, etc. I think the answer to this is to write the following in cc-cmds.el: (defun c-defun-name (&optional pos) "Return the name of the current function, or the one at POS. \"Function\" here means any named structure with a brace block, and \"current\" means the one surrounding point, starting or terminating at point. If there is no current function, return nil." ..... ) That should reduce the above `add-change-log-entry''s time to ~ 1 second. > > The problem is that it is impossible to decide without an unbounded > > search whether > > > > int foo [50] ; > > (char *) bar ; > > > > occurring at the outermost nesting level of a file.c is declaring global > > variables or is a k&r region declaring function parameters. > > I'd welcome suggestions as to how to speed it up, though. I can't see > > much alternative to what I've done (put a limit on 20 paren/bracket > > pairs in a k&r region) unless I put in a "column 0 heuristic", something > > I'd realy rather not do. > I'm puzzled that (parse-partial-sexp (point-min) (point-max)) completes > instantaneously here (without any paren/brackets limits). Isn't there some sort of cacheing of p-p-s? Anyhow, let us rejoice, not puzzle, over this. :-) -- Alan Mackenzie (Nuremberg, Germany).