[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Unbearably slow editing in .h files
From: |
Dan Nicolaescu |
Subject: |
Re: Unbearably slow editing in .h files |
Date: |
Thu, 03 Apr 2008 06:10:40 -0700 |
Alan Mackenzie <address@hidden> writes:
> 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.)
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
When used on a diff buffer with thousands of lines, it is a bit slow.
> > 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.
> 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...