Re: open large file with C code: is it realy should be so slow?

[Alan Mackenzie]

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 <address@hidden> 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.

> ------------------------------------------------------------------------------