[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Unbearably slow editing in .h files

From: martin rudalics
Subject: Re: Unbearably slow editing in .h files
Date: Sun, 24 Feb 2008 09:55:23 +0100
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

> Yes, very.  Sadly.  It takes about 18 seconds for me (1.2 GHz Athlon).
> However, it is having to analyze over 54kBytes of C source between EOB
> and EO-last-defun.  This time is taken up almost fully by the call to
> c-where-wrt-to-brace-construct.  Maybe this could be optimised.  Maybe,
> on the other hand, it's not reasonable to expect anything faster in this
> pathological case.

I think `c-beginning-of-defun' should also report an error within
reasonable time when defuns are malformed.  How about providing some
`c-fast-beginning-of-defun' mechanism which might not be able to cater
with all possible ways to write a defun but is reasonably fast for
well-written ones?

> By comparison, if you do the same in lread.c, it takes much less than a
> second.  It may be that the plethora of macros in lisp.h is causing the
> delay.

The plain idea of potentially scanning the entire buffer backwards is
tantalizing.  There should be some way to avoid that.

> However, there are two problems conflated in this thread.  There's the
> slowness in certain C files, and there's the way C-x 4 a calls
> c-\(beginning\|end\)-of-defun five times.  Lets separate them!
> 5 x 18s = 1.5 minutes.  This is the other thing that is slugging C-x 4 a.
> add-log-current-defun is _emulating_ c-where-wrt-to-brace-construct, and
> emulations tend to be slow.  ;-)

Sure.  I already mentioned in this thread that I fail to understand how
`add-log-current-defun' is organized.  The problem is: Changing that
function may implicitly alter the way change logs entries get written.
This could go on - for some time - unnoticed and lead to considerable
confusions afterwards.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]