From: Alan Mackenzie <acm@muc.de>
To: Dan Nicolaescu <dann@ics.uci.edu>
Cc: emacs-devel@gnu.org
Subject: Re: Unbearably slow editing in .h files
Date: Thu, 3 Apr 2008 14:17:03 +0000 [thread overview]
Message-ID: <20080403141703.GB1937@muc.de> (raw)
In-Reply-To: <200804031310.m33DAfB3009774@sallyv1.ics.uci.edu>
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).
next prev parent reply other threads:[~2008-04-03 14:17 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-04 21:18 patch: add-log.el: changelog find file under poin Jan Nieuwenhuizen
2007-11-06 23:45 ` Juri Linkov
2007-11-07 13:38 ` Jan Nieuwenhuizen
2007-11-09 8:40 ` Dan Nicolaescu
2007-11-09 9:40 ` Juri Linkov
2008-01-20 6:14 ` Richard Stallman
2008-01-21 3:02 ` Glenn Morris
2008-01-21 20:30 ` Richard Stallman
2008-01-21 20:35 ` Glenn Morris
2008-01-22 22:29 ` Richard Stallman
2008-01-22 22:38 ` Glenn Morris
2008-01-22 23:09 ` Dan Nicolaescu
2008-01-23 1:32 ` Juri Linkov
2008-01-23 2:25 ` Dan Nicolaescu
2008-01-23 9:28 ` Juri Linkov
2008-01-23 16:20 ` Richard Stallman
2008-01-27 19:54 ` Dan Nicolaescu
2008-01-28 10:20 ` martin rudalics
2008-01-30 2:58 ` Dan Nicolaescu
2008-02-18 19:46 ` patch: add-log.el: changelog find file under point martin rudalics
2008-02-18 20:09 ` Unbearably slow editing in .h files (was: patch: add-log.el: changelog find file under point) Stefan Monnier
2008-02-23 22:49 ` Alan Mackenzie
2008-02-23 22:51 ` Unbearably slow editing in .h files martin rudalics
2008-02-23 23:25 ` Alan Mackenzie
2008-02-24 8:55 ` martin rudalics
2008-04-02 22:07 ` Alan Mackenzie
2008-04-02 23:47 ` Dan Nicolaescu
2008-04-03 9:14 ` Alan Mackenzie
2008-04-03 13:10 ` Dan Nicolaescu
2008-04-03 14:17 ` Alan Mackenzie [this message]
2008-04-03 15:22 ` Dan Nicolaescu
2008-04-03 17:58 ` Alan Mackenzie
2008-02-24 0:37 ` Stefan Monnier
2008-02-24 8:39 ` Alan Mackenzie
2008-02-24 14:46 ` Jason Rumney
2008-02-24 19:48 ` Eli Zaretskii
2008-02-24 19:49 ` Eli Zaretskii
2008-02-24 10:28 ` Andreas Schwab
2008-02-24 13:49 ` Stefan Monnier
2008-02-24 14:41 ` Alan Mackenzie
2008-02-24 15:42 ` Stefan Monnier
2008-02-24 20:12 ` Alan Mackenzie
2008-02-24 22:29 ` Richard Stallman
2008-02-25 2:14 ` Stefan Monnier
2008-02-18 23:31 ` patch: add-log.el: changelog find file under point Juri Linkov
2008-02-19 6:34 ` martin rudalics
2008-02-20 21:29 ` Juri Linkov
2008-02-21 7:26 ` martin rudalics
2008-02-21 22:29 ` Richard Stallman
2008-02-22 19:26 ` martin rudalics
2008-02-23 19:28 ` Richard Stallman
2008-02-23 22:32 ` martin rudalics
2008-02-24 15:23 ` Richard Stallman
2008-02-24 15:23 ` Richard Stallman
2008-02-24 22:34 ` martin rudalics
2008-02-25 10:57 ` Richard Stallman
2008-02-25 14:05 ` martin rudalics
2008-01-22 0:08 ` patch: add-log.el: changelog find file under poin Juri Linkov
2008-01-22 1:17 ` Drew Adams
2008-01-22 9:54 ` Juri Linkov
2008-01-22 14:34 ` Drew Adams
2008-01-22 22:29 ` Richard Stallman
2008-01-23 1:29 ` Juri Linkov
2008-01-23 16:20 ` Richard Stallman
2008-01-28 8:55 ` Jan Nieuwenhuizen
2008-01-28 9:29 ` Johan Bockgård
2008-01-22 8:21 ` Dan Nicolaescu
2008-01-22 9:56 ` Juri Linkov
2008-01-22 23:13 ` Dan Nicolaescu
2008-01-22 22:29 ` Richard Stallman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080403141703.GB1937@muc.de \
--to=acm@muc.de \
--cc=dann@ics.uci.edu \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.