C mode too slow

C mode too slow

[Stefan Monnier]

> _and_ because editing lisp.h is virtually impossible these days.  I have
> to use an old Emacs - almost each editing step takes about 15 secs here
> with the more recent Emacs versions :-(

I tend to find editing code such as lisp.h too slow as well.
Can we do something about it?


        Stefan

Re: C mode too slow

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Tue, 07 Jun 2011 09:23:42 -0300
> 
> > _and_ because editing lisp.h is virtually impossible these days.  I have
> > to use an old Emacs - almost each editing step takes about 15 secs here
> > with the more recent Emacs versions :-(
> 
> I tend to find editing code such as lisp.h too slow as well.
> Can we do something about it?

Disable font-lock?

Re: C mode too slow

[Stefan Monnier]

>> > _and_ because editing lisp.h is virtually impossible these days.  I have
>> > to use an old Emacs - almost each editing step takes about 15 secs here
>> > with the more recent Emacs versions :-(
>> I tend to find editing code such as lisp.h too slow as well.
>> Can we do something about it?
> Disable font-lock?

I'd rather not have to resort to such a workaround.  As mentioned, using
an old Emacs works fine, even with font-lock.


        Stefan

Re: C mode too slow

[Nikodemus Siivola]

On 7 June 2011 20:57, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> I'd rather not have to resort to such a workaround.  As mentioned, using
> an old Emacs works fine, even with font-lock.

Just curious: do you have font-lock-verbose set to t by any chance?

Cheers,

 -- nikodemus

Re: C mode too slow

[Stefan Monnier]

>> I'd rather not have to resort to such a workaround.  As mentioned, using
>> an old Emacs works fine, even with font-lock.
> Just curious: do you have font-lock-verbose set to t by any chance?

No.


        Stefan

Re: C mode too slow

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Tue, 07 Jun 2011 14:57:16 -0300
> 
> >> > _and_ because editing lisp.h is virtually impossible these days.  I have
> >> > to use an old Emacs - almost each editing step takes about 15 secs here
> >> > with the more recent Emacs versions :-(
> >> I tend to find editing code such as lisp.h too slow as well.
> >> Can we do something about it?
> > Disable font-lock?
> 
> I'd rather not have to resort to such a workaround.

I didn't mean that as a workaround.  I meant to point out what I
thought was the reason for the slowdown.

Re: C mode too slow

[Stefan Monnier]

>> >> > _and_ because editing lisp.h is virtually impossible these days.
>> >> > I have to use an old Emacs - almost each editing step takes
>> >> > about 15 secs here with the more recent Emacs versions :-(
>> >> I tend to find editing code such as lisp.h too slow as well.
>> >> Can we do something about it?
>> > Disable font-lock?
>> I'd rather not have to resort to such a workaround.
> I didn't mean that as a workaround.  I meant to point out what I
> thought was the reason for the slowdown.

Oh, yes, it does seem strongly linked to font-lock.  There might be some
other ways to trigger the slowness, but usually if I disable font-lock
it's pretty responsive.


        Stefan

Re: C mode too slow

[Jindrich Makovicka]

On Tue, 07 Jun 2011 22:43:57 -0300
Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> >> >> > _and_ because editing lisp.h is virtually impossible these
> >> >> > days. I have to use an old Emacs - almost each editing step
> >> >> > takes about 15 secs here with the more recent Emacs
> >> >> > versions :-(
> >> >> I tend to find editing code such as lisp.h too slow as well.
> >> >> Can we do something about it?
> >> > Disable font-lock?
> >> I'd rather not have to resort to such a workaround.
> > I didn't mean that as a workaround.  I meant to point out what I
> > thought was the reason for the slowdown.
> 
> Oh, yes, it does seem strongly linked to font-lock.  There might be
> some other ways to trigger the slowness, but usually if I disable
> font-lock it's pretty responsive.

I set jit-lock-defer-time to 0.2, so the font locking at least doesn't
interfere with cursor motion (on 2.67GHz Core-i5). Makes Emacs a lot
more responsive.

-- 
Jindrich Makovicka

Re: C mode too slow

[Alan Mackenzie]

Hi, Stefan

>> _and_ because editing lisp.h is virtually impossible these days.  I
>> have to use an old Emacs - almost each editing step takes about 15
>> secs here with the more recent Emacs versions :-(

> I tend to find editing code such as lisp.h too slow as well.  Can we
> do something about it?

lisp.h is slow in "brace desserts", since CC Mode uses braces as anchor
points, particularly whilst font locking.  This should have been fixed
by the optimisation of c-parse-state.

However, comparing the trunk with Emacs 23.3 the number of calls to
c-parse-state has increased by a factor of ~9, cancelling out the
optimisation.  :-(  I'm looking to see why this has happened.

I'm actually looking at a large file (without a single brace) called
AT91SAM9263_INC.h, the one which triggered this optimisation.  What
seems to me slow in lisp.h is scrolling over areas which haven't yet
been fontified since loading.  Once that is done, I think things move at
a decent speed.  Is there anything particular, other than initial
scrolling, which is very slow in lisp.h?

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: C mode too slow

[Alan Mackenzie]

Hi, Stefan,

On Sun, Jun 12, 2011 at 08:38:11PM +0000, Alan Mackenzie wrote:

> >> _and_ because editing lisp.h is virtually impossible these days.  I
> >> have to use an old Emacs - almost each editing step takes about 15
> >> secs here with the more recent Emacs versions :-(

> > I tend to find editing code such as lisp.h too slow as well.  Can we
> > do something about it?

> lisp.h is slow in "brace desserts", since CC Mode uses braces as anchor
> points, particularly whilst font locking.  This should have been fixed
> by the optimisation of c-parse-state.

> However, comparing the trunk with Emacs 23.3 the number of calls to
> c-parse-state has increased by a factor of ~9, cancelling out the
> optimisation.  :-(  I'm looking to see why this has happened.

> I'm actually looking at a large file (without a single brace) called
> AT91SAM9263_INC.h, the one which triggered this optimisation.  What
> seems to me slow in lisp.h is scrolling over areas which haven't yet
> been fontified since loading.  Once that is done, I think things move at
> a decent speed.  Is there anything particular, other than initial
> scrolling, which is very slow in lisp.h?

Could you try editing lisp.h after applying this patch, please, and let
me know how it goes:



*** cc-fonts.el.~7~	2011-02-04 22:10:01.000000000 +0000
--- cc-fonts.el	2011-06-13 14:49:30.000000000 +0000
***************
*** 1192,1198 ****
  		;; Are we at a declarator?  Try to go back to the declaration
  		;; to check this.  Note that `c-beginning-of-decl-1' is slow,
  		;; so we cache its result between calls.
! 		(let (paren-state bod-res encl-pos is-typedef)
  		  (goto-char start-pos)
  		  (save-excursion
  		    (unless (and decl-search-lim
--- 1192,1200 ----
  		;; Are we at a declarator?  Try to go back to the declaration
  		;; to check this.  Note that `c-beginning-of-decl-1' is slow,
  		;; so we cache its result between calls.
! 		(let (paren-state bod-res encl-pos is-typedef
! 				  c-recognize-knr-p) ; Strictly speaking bogus,
! 					; but it speeds lisp.h up tremendously.
  		  (goto-char start-pos)
  		  (save-excursion
  		    (unless (and decl-search-lim


-- 
Alan Mackenzie (Nuremberg, Germany).

Re: C mode too slow

[Stefan Monnier]

> Could you try editing lisp.h after applying this patch, please, and let
> me know how it goes:

It seems to be a lot better now, thank you,


        Stefan