[Top][All Lists]
[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.