all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* C mode too slow
       [not found] <4DEDC752.7090604@gmx.at>
@ 2011-06-07 12:23 ` Stefan Monnier
  2011-06-07 14:12   ` Eli Zaretskii
  0 siblings, 1 reply; 11+ messages in thread
From: Stefan Monnier @ 2011-06-07 12:23 UTC (permalink / raw)
  To: emacs-devel

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



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: C mode too slow
  2011-06-07 12:23 ` C mode too slow Stefan Monnier
@ 2011-06-07 14:12   ` Eli Zaretskii
  2011-06-07 17:57     ` Stefan Monnier
  0 siblings, 1 reply; 11+ messages in thread
From: Eli Zaretskii @ 2011-06-07 14:12 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: C mode too slow
  2011-06-07 14:12   ` Eli Zaretskii
@ 2011-06-07 17:57     ` Stefan Monnier
  2011-06-07 18:45       ` Nikodemus Siivola
  2011-06-07 20:14       ` Eli Zaretskii
  0 siblings, 2 replies; 11+ messages in thread
From: Stefan Monnier @ 2011-06-07 17:57 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: C mode too slow
  2011-06-07 17:57     ` Stefan Monnier
@ 2011-06-07 18:45       ` Nikodemus Siivola
  2011-06-08  1:42         ` Stefan Monnier
  2011-06-07 20:14       ` Eli Zaretskii
  1 sibling, 1 reply; 11+ messages in thread
From: Nikodemus Siivola @ 2011-06-07 18:45 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Eli Zaretskii, emacs-devel

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



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: C mode too slow
  2011-06-07 17:57     ` Stefan Monnier
  2011-06-07 18:45       ` Nikodemus Siivola
@ 2011-06-07 20:14       ` Eli Zaretskii
  2011-06-08  1:43         ` Stefan Monnier
  1 sibling, 1 reply; 11+ messages in thread
From: Eli Zaretskii @ 2011-06-07 20:14 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

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




^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: C mode too slow
  2011-06-07 18:45       ` Nikodemus Siivola
@ 2011-06-08  1:42         ` Stefan Monnier
  0 siblings, 0 replies; 11+ messages in thread
From: Stefan Monnier @ 2011-06-08  1:42 UTC (permalink / raw)
  To: Nikodemus Siivola; +Cc: Eli Zaretskii, emacs-devel

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



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: C mode too slow
  2011-06-07 20:14       ` Eli Zaretskii
@ 2011-06-08  1:43         ` Stefan Monnier
  2011-06-08  7:30           ` Jindrich Makovicka
  0 siblings, 1 reply; 11+ messages in thread
From: Stefan Monnier @ 2011-06-08  1:43 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: C mode too slow
  2011-06-08  1:43         ` Stefan Monnier
@ 2011-06-08  7:30           ` Jindrich Makovicka
  0 siblings, 0 replies; 11+ messages in thread
From: Jindrich Makovicka @ 2011-06-08  7:30 UTC (permalink / raw)
  To: emacs-devel

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





^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: C mode too slow
@ 2011-06-12 20:38 Alan Mackenzie
  2011-06-13 14:59 ` Alan Mackenzie
  0 siblings, 1 reply; 11+ messages in thread
From: Alan Mackenzie @ 2011-06-12 20:38 UTC (permalink / raw)
  To: emacs-devel, Stefan Monnier

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



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: C mode too slow
  2011-06-12 20:38 Alan Mackenzie
@ 2011-06-13 14:59 ` Alan Mackenzie
  2011-06-20 21:10   ` Stefan Monnier
  0 siblings, 1 reply; 11+ messages in thread
From: Alan Mackenzie @ 2011-06-13 14:59 UTC (permalink / raw)
  To: emacs-devel, Stefan Monnier

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



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: C mode too slow
  2011-06-13 14:59 ` Alan Mackenzie
@ 2011-06-20 21:10   ` Stefan Monnier
  0 siblings, 0 replies; 11+ messages in thread
From: Stefan Monnier @ 2011-06-20 21:10 UTC (permalink / raw)
  To: Alan Mackenzie; +Cc: emacs-devel

> 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



^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2011-06-20 21:10 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <4DEDC752.7090604@gmx.at>
2011-06-07 12:23 ` C mode too slow Stefan Monnier
2011-06-07 14:12   ` Eli Zaretskii
2011-06-07 17:57     ` Stefan Monnier
2011-06-07 18:45       ` Nikodemus Siivola
2011-06-08  1:42         ` Stefan Monnier
2011-06-07 20:14       ` Eli Zaretskii
2011-06-08  1:43         ` Stefan Monnier
2011-06-08  7:30           ` Jindrich Makovicka
2011-06-12 20:38 Alan Mackenzie
2011-06-13 14:59 ` Alan Mackenzie
2011-06-20 21:10   ` Stefan Monnier

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.