Re: Unbearably slow editing in .h files

[Dan Nicolaescu <dann@ics.uci.edu>]

Alan Mackenzie <acm@muc.de> writes:

  > On Wed, Apr 02, 2008 at 04:47:52PM -0700, Dan Nicolaescu wrote:
  > > Alan Mackenzie <acm@muc.de> 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...