Re: Unbearably slow editing in .h files

[Alan Mackenzie <acm@muc.de>]

Hi, Dan!

On Thu, Apr 03, 2008 at 06:10:40AM -0700, Dan Nicolaescu wrote:
> 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:
>   > >   > 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

Wow!  I've just tried this.  It's amazing!  There are one or two things
in it which aren't quite right, though.

> When used on a diff buffer with thousands of lines, it is a bit slow.

Hmmm.  I've only tried it on diffs with elisp files.  That was a little
slow.  Do you mean it's _very_ slow with C file diffs?  Can you give some
numbers here?  Processor speed, size of diff file, time it takes.  But
then again, people are only going to be using it once or twice per patch
(and then having to fill out the result by hand), so it is surely not
that critical.  But if it were taking 20 minutes rather than 45 seconds,
that would be too slow, I agree.

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

I'd be very interested to here how much faster C-x 4 A has become as a
result of this patch and my patch on Friday 2008-03-07 to cc-engine.el.

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

Well, one set of users who still use K&R is the Emacs development team.
;-)  It would be possible, and very easy, to make K&R a user option.  But
I don't think that's the right thing to do.

The overhead that K&R imposes on C-M-a and C-x 4 a is not _that_ high,
and it will diminish as processors continue to get faster.  I recently
put in a hard-coded limit to the number of parameter declarations in a
K&R section.  That limit is currently 20. 

-- 
Alan Mackenzie (Nuremberg, Germany).