Re: Unbearably slow editing in .h files

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

Alan Mackenzie <acm@muc.de> writes:

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

Yep, it should not generate duplicate entries.
One possible improvement is that it should iterate at a lower
granularity than a hunk, some hunks have changes ! + and - changes.
(but that's still not enough, a + hunk could be adding 5 functions...)

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

Unfortunately I don't have any massive patches handy, so I can't test
now how much things have improved for exactly the things that had
problems before.  But some quick tests with the diff for lisp.h revision
1.606 (i.e. something that had a long ChangeLog entry, 625 lines
unidiff) showed that things have improved quite a lot today vs a > 1
month old emacs (a few seconds vs > 2 minutes).
Which is great. Thanks!

Trying C-x 4 A on a 4-5000 lines patch would be more interesting...

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

Ideally in the future C-x 4 A should be done automatically when doing a
checkin, that why it is important to be as fast as possible.


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

See above.

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

Yeah, and many people wish that would change at some point.  But that a
separate discussion that we should get into now.

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

Just exploring options here...
Would simply ignoring K&R for the purpose or running C-x 4 a  work?
Yes, it might generate the wrong name in the ChangeLog entry in some
very limited cases (is that true?), but that's not very critical.