emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Unbearably slow editing in .h files


From: Alan Mackenzie
Subject: Re: Unbearably slow editing in .h files
Date: Thu, 3 Apr 2008 09:14:00 +0000
User-agent: Mutt/1.5.9i

Hi, Dan!

On Wed, Apr 02, 2008 at 04:47:52PM -0700, Dan Nicolaescu wrote:
> Alan Mackenzie <address@hidden> writes:

>   > Hi, Martin and Stefan,

>   > On Sat, Feb 23, 2008 at 11:51:34PM +0100, martin rudalics wrote:
>   > > Evening Alan,

>   > > > What is add-log-current-defun using c-beginning-of-defun for?

>   > > Visit lisp.h, go to the end of the buffer, and do

>   > > M-x RET c-beginning-of-defun RET

>   > > Convincing?

>   > 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.)

> 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?  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.

> Thanks

>         --dan

-- 
Alan.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]