* Re: open large file with C code: is it realy should be so slow?
2009-01-04 22:07 ` Dave Milter
@ 2009-01-04 23:31 ` Alan Mackenzie
2009-11-01 17:01 ` Dave Milter
2009-01-06 0:01 ` Richard M Stallman
2009-12-04 15:25 ` Alan Mackenzie
2 siblings, 1 reply; 16+ messages in thread
From: Alan Mackenzie @ 2009-01-04 23:31 UTC (permalink / raw)
To: Dave Milter; +Cc: bug-cc-mode, emacs-devel
Hi, Dave,
I'm actually working on this bug at the moment. With the Yuletide break,
and so on, I've kind of lost the thread a bit and I got bogged down in
the complexities of the code. I should have got back to you sooner;
sorry!
On Mon, Jan 05, 2009 at 01:07:18AM +0300, Dave Milter wrote:
> On Mon, Dec 1, 2008 at 3:37 PM, Alan Mackenzie <acm@muc.de> wrote:
> > On Mon, Dec 01, 2008 at 01:01:08PM +0300, Dave Milter wrote:
> >> I have problem with emacs responsibility,
> >> I work with large enough C header files,
> >> and when I want to scroll it using mouse's wheel or
> >> page (up|down) keys emacs stop react on any keys, like (ctrl+g),
> >> and eats 100% of CPU's time during long period,
> >> I wonder is this a bug, or expected behaviour?
> > It's a bug.
> > Although C Mode works "properly" here, it doesn't seem to be tuned
> > very well for files like this one (At91SAM9253_inc.h), which contain
> > a lot of #defines and comments and nothing else.
> I made some more testing (to find out problem in "file", or in "large"),
> because of really want to see this bug fixed,
It will be fixed, hopefully within the next few days. It's too serious a
bug not to fix.
> I see the same behaviour on file created by
> for ((i=0;i<500;++i)); do echo "extern void f${i}(int a${i});"; done
Yes. The CC Mode function which is to blame is `c-parse-state'. It
maintains a "cache" of (essentially) brace pairs, using the positions of
these braces to scan from. In a "brace desert", it scans from the
beginning of the buffer, sometimes many times per (scroll) command, and
this is why it is so slow.
To see this, create an alternative file like this:
for ((i=0;i<500;++i)); do echo "extern void f${i}(int a${i}) {}"; done
^^
Scrolling in this file will be instantaneous, as it should be.
> emacs from cvs and emacs 22 show the same behaviour -
> eating 100% of cpu, if make fast scrolling.
Yes.
[ .... ]
> In fact, with small files, for example the same script but 5000 -> 500,
> I see the same situation, but after eating cpu during some period,
> it never eating it after, and all works smoothly,
> while with big files it eats it every fast scroll.
If you profile the stuff in cc-engine.el, you'll see c-parse-state right
at the top.
--
Alan Mackenzie (Nuremberg, Germany).
------------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: open large file with C code: is it realy should be so slow?
2009-01-04 23:31 ` Alan Mackenzie
@ 2009-11-01 17:01 ` Dave Milter
0 siblings, 0 replies; 16+ messages in thread
From: Dave Milter @ 2009-11-01 17:01 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: bug-cc-mode, emacs-devel
On Mon, Jan 5, 2009 at 2:31 AM, Alan Mackenzie <acm@muc.de> wrote:
> Hi, Dave,
>
> I'm actually working on this bug at the moment. With the Yuletide break,
> and so on, I've kind of lost the thread a bit and I got bogged down in
> the complexities of the code. I should have got back to you sooner;
> sorry!
>
Hi,
was something changed?
I recently give a try emacs 23.1, and the bug still here:
font-lock-fontify-region 27
128.543602 4.7608741481
font-lock-default-fontify-region 27
128.54316500 4.7608579629
font-lock-fontify-keywords-region 27
128.14446099 4.7460911481
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: open large file with C code: is it realy should be so slow?
2009-01-04 22:07 ` Dave Milter
2009-01-04 23:31 ` Alan Mackenzie
@ 2009-01-06 0:01 ` Richard M Stallman
2009-01-06 5:52 ` Chong Yidong
2009-01-06 19:03 ` Alan Mackenzie
2009-12-04 15:25 ` Alan Mackenzie
2 siblings, 2 replies; 16+ messages in thread
From: Richard M Stallman @ 2009-01-06 0:01 UTC (permalink / raw)
To: Dave Milter; +Cc: bug-cc-mode, acm, emacs-devel
I too find C mode painfully slow these days. I wonder what changed to
make it so much slower than it was. Perhaps the only relevant change
is that Font Lock is now enabled; I never used to enable it. Even so,
it must make a lot of users unhappy.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: open large file with C code: is it realy should be so slow?
2009-01-06 0:01 ` Richard M Stallman
@ 2009-01-06 5:52 ` Chong Yidong
2009-01-06 22:59 ` Richard M Stallman
2009-01-06 19:03 ` Alan Mackenzie
1 sibling, 1 reply; 16+ messages in thread
From: Chong Yidong @ 2009-01-06 5:52 UTC (permalink / raw)
To: rms; +Cc: bug-cc-mode, acm, Dave Milter, emacs-devel
Richard M Stallman <rms@gnu.org> writes:
> I too find C mode painfully slow these days. I wonder what changed to
> make it so much slower than it was. Perhaps the only relevant change
> is that Font Lock is now enabled; I never used to enable it. Even so,
> it must make a lot of users unhappy.
You are likely using an exceptionally slow computer. There are certain
special situations in which a C-mode slowdown is observable, but it
should be fine in normal usage, at least in my experience (I am using a
fairly slow Pentium IV, and do not experience C-mode slowness when
editing the Emacs source code).
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: open large file with C code: is it realy should be so slow?
2009-01-06 5:52 ` Chong Yidong
@ 2009-01-06 22:59 ` Richard M Stallman
2009-01-07 1:16 ` Chong Yidong
0 siblings, 1 reply; 16+ messages in thread
From: Richard M Stallman @ 2009-01-06 22:59 UTC (permalink / raw)
To: Chong Yidong; +Cc: bug-cc-mode, acm, davemilter, emacs-devel
> I too find C mode painfully slow these days. I wonder what changed to
> make it so much slower than it was. Perhaps the only relevant change
> is that Font Lock is now enabled; I never used to enable it. Even so,
> it must make a lot of users unhappy.
You are likely using an exceptionally slow computer.
I am using a Lemote Yeeloong, which could well be the machine
we will recommend to the public for the coming year or more.
I just did some testing and I am obliged to modify my complaint.
It seems that the slowness is mainly in _loading_ C mode.
Visiting buffer.h, when it is the first C file I visit,
just took 20 seconds. However, once C mode is loaded,
visiting buffer.h again is pretty fast.
------------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: open large file with C code: is it realy should be so slow?
2009-01-06 22:59 ` Richard M Stallman
@ 2009-01-07 1:16 ` Chong Yidong
2009-01-08 11:37 ` Richard M Stallman
0 siblings, 1 reply; 16+ messages in thread
From: Chong Yidong @ 2009-01-07 1:16 UTC (permalink / raw)
To: rms; +Cc: bug-cc-mode, acm, davemilter, emacs-devel
Richard M Stallman <rms@gnu.org> writes:
> I just did some testing and I am obliged to modify my complaint. It
> seems that the slowness is mainly in _loading_ C mode.
>
> Visiting buffer.h, when it is the first C file I visit, just took 20
> seconds. However, once C mode is loaded, visiting buffer.h again is
> pretty fast.
Loading cc-mode in Emacs 23 takes 0.33 seconds on my current laptop
(about 0.3 seconds for Emacs 22).
Apparently, the netbook you are using (Lemote Yeeloong) has a 600-800
MHz processor. That shouldn't be so slow as to yield 20 second loading
times. There's likely something strange going on. Could you try with
Emacs 22 and see if the problem recurs there?
------------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: open large file with C code: is it realy should be so slow?
2009-01-07 1:16 ` Chong Yidong
@ 2009-01-08 11:37 ` Richard M Stallman
2009-01-08 12:42 ` Alan Mackenzie
0 siblings, 1 reply; 16+ messages in thread
From: Richard M Stallman @ 2009-01-08 11:37 UTC (permalink / raw)
To: Chong Yidong; +Cc: bug-cc-mode, acm, davemilter, emacs-devel
Apparently, the netbook you are using (Lemote Yeeloong) has a 600-800
MHz processor. That shouldn't be so slow as to yield 20 second loading
times. There's likely something strange going on. Could you try with
Emacs 22 and see if the problem recurs there?
Visiting the small .c file below takes around 2 seconds in Emacs 22.
It takes 15 or 20 seconds in Emacs 23. In both cases I used -Q
and visited the file first thing after Emacs started.
char *p = 0;
main ()
{
*p = 1;
}
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: open large file with C code: is it realy should be so slow?
2009-01-08 11:37 ` Richard M Stallman
@ 2009-01-08 12:42 ` Alan Mackenzie
0 siblings, 0 replies; 16+ messages in thread
From: Alan Mackenzie @ 2009-01-08 12:42 UTC (permalink / raw)
To: Richard M Stallman; +Cc: bug-cc-mode, Chong Yidong, davemilter, emacs-devel
Hi, Richard,
On Thu, Jan 08, 2009 at 06:37:52AM -0500, Richard M Stallman wrote:
> Apparently, the netbook you are using (Lemote Yeeloong) has a 600-800
> MHz processor. That shouldn't be so slow as to yield 20 second loading
> times. There's likely something strange going on. Could you try with
> Emacs 22 and see if the problem recurs there?
> Visiting the small .c file below takes around 2 seconds in Emacs 22.
> It takes 15 or 20 seconds in Emacs 23. In both cases I used -Q
> and visited the file first thing after Emacs started.
Could you try in Emacs-23 with the CC Mode from Emacs-22, and vice
versa? CC Mode is in .../lisp/progmodes/cc-*.elc
Thanks!
--
Alan Mackenzie (Nuremberg, Germany).
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: open large file with C code: is it realy should be so slow?
2009-01-06 0:01 ` Richard M Stallman
2009-01-06 5:52 ` Chong Yidong
@ 2009-01-06 19:03 ` Alan Mackenzie
2009-01-06 21:50 ` Stefan Monnier
1 sibling, 1 reply; 16+ messages in thread
From: Alan Mackenzie @ 2009-01-06 19:03 UTC (permalink / raw)
To: Richard M Stallman; +Cc: bug-cc-mode, Dave Milter, emacs-devel
Hi, Richard!
On Mon, Jan 05, 2009 at 07:01:26PM -0500, Richard M Stallman wrote:
> I too find C mode painfully slow these days. I wonder what changed to
> make it so much slower than it was. Perhaps the only relevant change
> is that Font Lock is now enabled; I never used to enable it. Even so,
> it must make a lot of users unhappy.
First of all, sorry.
Font lock consumes masses of cycles, yes. Set
`font-lock-maximum-decoration' to 2; that might make it fast enough.
But no, not too many users seem too unhappy about it - at least, not
those who complain on bug-cc-mode@gnu.org or emacs-devel. Or, more
accurately, most complaints received have been because of specific
pessimisations which only manifest themselves in peculiar files (as in
the current thread) or in very big files. These are relatively easy to
fix.
What speed of processor have you got? With my 1.2 GHz Athlon, there is
a brief pause (~ 1 second) every now and then, while caches get checked
(not cheques getting cashed), and suchlike. When I type, sometimes the
display is quite a few characters behind the keyboard. But pauses like
that don't bother me too much; I just carry on typing, subconsciously
confident that Emacs will cache up soon enough. But that's just me.
>From the tone of your post, I'm guessing that you're generally irritated
by sluggishness in C Mode rather because of any specific long wait.
There is at least one "peculiar" file in emacs, .../src/lisp.h in which C
Mode is sluggish locating BODs because of the number of #defines in it -
that shows up if you do C-x 4 a at its EOF. But is there anything in
particular you've noticed which is particularly painful?
I'd guess that C Mode slowed down quite a lot in CC Mode 5.30, when the
font locking was taken into CC Mode, with the default decoration level
(3), prioritising accuracy over speed. Since then, I've added a bit of
scanning to set syntax-table text properties so that the following sort
of stuff doesn't foul up parse-partial-sexp:
#define LBRACE {
#error unbalanced single quotes can't be ruled out.
K&R style declarations (more precisely, having to check for them) causes
quite a slow down. They're never(?) used in modern C code, so maybe we
could flush them from .../src/*.[ch] and make K&R parsing an option.
--
Alan Mackenzie (Nuremberg, Germany).
------------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: open large file with C code: is it realy should be so slow?
2009-01-06 19:03 ` Alan Mackenzie
@ 2009-01-06 21:50 ` Stefan Monnier
0 siblings, 0 replies; 16+ messages in thread
From: Stefan Monnier @ 2009-01-06 21:50 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: bug-cc-mode, Richard M Stallman, Dave Milter, emacs-devel
> (not cheques getting cashed), and suchlike. When I type, sometimes the
> display is quite a few characters behind the keyboard. But pauses like
> that don't bother me too much; I just carry on typing, subconsciously
> confident that Emacs will cache up soon enough. But that's just me.
I can live with them as well, but such files were perfectly editable
without any such delays even on much slower processors, not that
long ago. So I don't think such delays should be considered acceptable,
except in pathological cases.
> I'd guess that C Mode slowed down quite a lot in CC Mode 5.30, when the
> font locking was taken into CC Mode, with the default decoration level
> (3), prioritising accuracy over speed. Since then, I've added a bit of
It looks like it indeed. I'm wondering if it was a good decision: maybe
I've just learned to live with the previous inaccuracies, but I have the
impression that I've seen more font-locking errors with the "new"
font-locking than with the old one: maybe it's more accurate, but only
as long as its cache doesn't get out-of-date/garbled.
More specifically, I still regularly see function definitions that are not
properly highlighted (presumably because the cache indicates that it's
not at top-level, even tho it is).
Also accuracy is basically impossible in the presence of funky CPP
macros, and it's already very difficult in actual code, because of
things like
#if foo
{
blabla
#else
blibli;
{
toto;
#endif
Emacs has traditionally taken the "shallow" approach, using lexical cues
rather than full blown syntactic analysis, and this has served it fairly
well. Both approaches have their downsides.
Stefan
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: open large file with C code: is it realy should be so slow?
2009-01-04 22:07 ` Dave Milter
2009-01-04 23:31 ` Alan Mackenzie
2009-01-06 0:01 ` Richard M Stallman
@ 2009-12-04 15:25 ` Alan Mackenzie
2009-12-19 10:51 ` Dave Milter
2 siblings, 1 reply; 16+ messages in thread
From: Alan Mackenzie @ 2009-12-04 15:25 UTC (permalink / raw)
To: Dave Milter; +Cc: bug-cc-mode, emacs-devel
Hi, Dave!
I've got this problem fixed, and have committed the new versions of the
CC Mode files (in particular, cc-engine.el, cc-mode.el, cc-defs.el,
cc-fonts.el, cc-langs.el) to both the CC Mode project at
http://cc-mode.sf.net/ and the main Emacs repository at
http://cvs.savannah.gnu.org/viewvc/emacs/emacs/lisp/progmodes/.
Normally, I'd send you a patch, but you reported the bug so long ago, and
the patch would be enormous, so I think it's best if you could just
download the new version. If this is awkward for any reason, get back in
touch and I'll email you the files. Please try out this new version, and
let me know if it's not up to scratch.
Once again, thanks for the original bug report, and once again, sorry
it's taken so long to fix.
Sincerely,
--
Alan Mackenzie (Nuremberg, Germany).
On Mon, Jan 05, 2009 at 01:07:18AM +0300, Dave Milter wrote:
> On Mon, Dec 1, 2008 at 3:37 PM, Alan Mackenzie <acm@muc.de> wrote:
> > On Mon, Dec 01, 2008 at 01:01:08PM +0300, Dave Milter wrote:
> >> I have problem with emacs responsibility,
> >> I work with large enough C header files,
> >> and when I want to scroll it using mouse's wheel or
> >> page (up|down) keys emacs stop react on any keys, like (ctrl+g),
> >> and eats 100% of CPU's time during long period,
> >> I wonder is this a bug, or expected behaviour?
> > It's a bug.
> > Although C Mode works "properly" here, it doesn't seem to be tuned very
> > well for files like this one (At91SAM9253_inc.h), which contain a lot of
> > #defines and comments and nothing else.
> I made some more testing (to find out problem in "file", or in "large"),
> because of really want to see this bug fixed,
> I see the same behaviour on file created by
> for ((i=0;i<500;++i)); do echo "extern void f${i}(int a${i});"; done
> emacs from cvs and emacs 22 show the same behaviour -
> eating 100% of cpu, if make fast scrolling.
> >> elp results are:
> Function Name Call Count
> Elapsed Time Average Time
> ========================================================= ==========
> ============ ============
> font-lock-fontify-region 41
> 230.65321899 5.6256882682
> font-lock-default-fontify-region 41
> 230.65264900 5.6256743658
> font-lock-fontify-keywords-region 41
> 230.61167599 5.6246750243
> font-lock-fontify-syntactically-region 41
> 0.039573 0.0009651951
> font-lock-unfontify-region 41
> 0.0005050000 1.231...e-05
> font-lock-default-unfontify-region 41
> 0.0001930000 4.707...e-06
> font-lock-extend-region-wholelines 41
> 0.0001080000 2.634...e-06
> font-lock-extend-region-multiline 41
> 9.800...e-05 2.390...e-06
> font-lock-set-defaults 41
> 8.299...e-05 2.024...e-06
> font-lock-mode 3
> 7.6e-05 2.533...e-05
> font-lock-default-function 3
> 1.400...e-05 4.666...e-06
> In fact, with small files, for example the same script but 5000 -> 500,
> I see the same situation, but after eating cpu during some period,
> it never eating it after, and all works smoothly,
> while with big files it eats it every fast scroll.
> ------------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: open large file with C code: is it realy should be so slow?
2009-12-04 15:25 ` Alan Mackenzie
@ 2009-12-19 10:51 ` Dave Milter
2009-12-27 10:33 ` Dave Milter
0 siblings, 1 reply; 16+ messages in thread
From: Dave Milter @ 2009-12-19 10:51 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: bug-cc-mode, emacs-devel
On Fri, Dec 4, 2009 at 6:25 PM, Alan Mackenzie <acm@muc.de> wrote:
> Hi, Dave!
>
> I've got this problem fixed, and have committed the new versions of the
> CC Mode files (in particular, cc-engine.el, cc-mode.el, cc-defs.el,
> cc-fonts.el, cc-langs.el) to both the CC Mode project at
> http://cc-mode.sf.net/ and the main Emacs repository at
> http://cvs.savannah.gnu.org/viewvc/emacs/emacs/lisp/progmodes/.
>
> Normally, I'd send you a patch, but you reported the bug so long ago, and
> the patch would be enormous, so I think it's best if you could just
> download the new version. If this is awkward for any reason, get back in
> touch and I'll email you the files. Please try out this new version, and
> let me know if it's not up to scratch.
>
> Once again, thanks for the original bug report, and once again, sorry
> it's taken so long to fix.
>
Hi,
I tried emacs-cvs package from my Linux distributive.
M-x version says that it is GNU Emacs 23.1.90.1.
It much, much better then previous version, yes it still eats cpu,
during fast scrolling, but not continuosly, and stop eat cpu, after I
scroll all file.
But I faced with another problem, have no idea is it related to new
code in c-mode.
Time to time magic tab stop working.
For example, I have code like this
if (foo) {
}
I insert line after if (foo) {
if (foo) {
if (boo) {
}
tab not move "if (boo) {" to position with right indentation.
But if I kill buffer, and repopen file all works as expected.
I can not find way to constantly reproduce this bug,
this happened time to time, when I insert a couple of lines into
existing code, <tab> stop working in right way, I kill buffer,
open file again, and all works.
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: open large file with C code: is it realy should be so slow?
2009-12-19 10:51 ` Dave Milter
@ 2009-12-27 10:33 ` Dave Milter
0 siblings, 0 replies; 16+ messages in thread
From: Dave Milter @ 2009-12-27 10:33 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: bug-cc-mode, emacs-devel
On Sat, Dec 19, 2009 at 1:51 PM, Dave Milter <davemilter@gmail.com> wrote:
> Hi,
>
> I tried emacs-cvs package from my Linux distributive.
> M-x version says that it is GNU Emacs 23.1.90.1.
>
> It much, much better then previous version, yes it still eats cpu,
> during fast scrolling, but not continuosly, and stop eat cpu, after I
> scroll all file.
>
> But I faced with another problem, have no idea is it related to new
> code in c-mode.
>
> Time to time magic tab stop working.
>
> For example, I have code like this
> if (foo) {
> }
> I insert line after if (foo) {
> if (foo) {
> if (boo) {
> }
> tab not move "if (boo) {" to position with right indentation.
>
> But if I kill buffer, and repopen file all works as expected.
> I can not find way to constantly reproduce this bug,
> this happened time to time, when I insert a couple of lines into
> existing code, <tab> stop working in right way, I kill buffer,
> open file again, and all works.
>
I was able to reproduce it constantly.
Open empty file C file, for example
/tmp/1.c
type
#include <stdio.h><enter>
<enter>
int main(int argc, char *argv[])<enter>
{<enter>
}<enter>
after that save and go to "{"
type enter and wrote:
if (argc < 3) {<enter>
}<enter>
aftern that tab will not move "if (argc < 3)" to right position.
^ permalink raw reply [flat|nested] 16+ messages in thread