A significant slowdown calling font-lock-fontify-buffer from a hook

A significant slowdown calling font-lock-fontify-buffer from a hook

[Juanma Barranquero]

I discovered this because I call colum-marker-1 (from
colum-marker-mode, http://www.emacswiki.org/emacs/column-marker.el) in
the prog-mode-hook, but the issue is with font-lock-fontify-buffer.

emacs -Q --eval "(add-hook 'prog-mode-hook
#'font-lock-fontify-buffer)" src/xdisp.c -f kill-emacs

On Emacs 24.3, -O0 -g3 --enable-checking: about 2 seconds.
On trunk, -O2 -g3 --enable-checking: ~ 33 seconds, x16 slowdown.

Any idea what could be causing this?

    J

Re: A significant slowdown calling font-lock-fontify-buffer from a hook

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Tue, 16 Jul 2013 02:12:40 +0200
> 
> I discovered this because I call colum-marker-1 (from
> colum-marker-mode, http://www.emacswiki.org/emacs/column-marker.el) in
> the prog-mode-hook, but the issue is with font-lock-fontify-buffer.
> 
> emacs -Q --eval "(add-hook 'prog-mode-hook
> #'font-lock-fontify-buffer)" src/xdisp.c -f kill-emacs
> 
> On Emacs 24.3, -O0 -g3 --enable-checking: about 2 seconds.
> On trunk, -O2 -g3 --enable-checking: ~ 33 seconds, x16 slowdown.
> 
> Any idea what could be causing this?

Is the "calling from a hook" an important part of this issue?  If so,
why?

I tried this:

  emacs -Q
  M-x global-font-lock-mode RET
  C-x C-f src/xdisp.c RET
  M-: (font-lock-fontify-buffer) RET

Is this a valid way of reproducing the slowdown?  If so, modify the
last command to start the profiler before invoking
font-lock-fontify-buffer and stop it after it returns, and you will
see that the current trunk calls a certain bunch of functions at least
five-fold more times than Emacs 24.3.  Could that be the reason?

Re: A significant slowdown calling font-lock-fontify-buffer from a hook

[Juanma Barranquero]

> Is the "calling from a hook" an important part of this issue?

Doing

  emacs -Q src/xdisp.c
  M-x font-lock-fontify-buffer <RET>

I don't see the slowdown.

> If so, why?

If you ask, why fails from the hook? I don't know. If the question is,
why do I run font-lock-fontify-buffer from a hook? I don't, but I run
column-marker-1 (from column-marker.el) which calls
font-lock-fontify-buffer.

> Is this a valid way of reproducing the slowdown?

No. If it were, you would notice it. I noticed it because suddenly
loading big source code files was so slow I initially though Emacs was
hung up.

> the current trunk calls a certain bunch of functions at least
> five-fold more times than Emacs 24.3.  Could that be the reason?

Perhaps. I'll look into it.

Thanks,

   Juanma

Re: A significant slowdown calling font-lock-fontify-buffer from a hook

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Tue, 16 Jul 2013 20:26:56 +0200
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> > Is the "calling from a hook" an important part of this issue?
> 
> Doing
> 
>   emacs -Q src/xdisp.c
>   M-x font-lock-fontify-buffer <RET>
> 
> I don't see the slowdown.

First, you need to turn off global-font-lock-mode before visiting
xdisp.c.  Second, if you do turn off global-font-lock-mode, invoking
font-lock-fontify-buffer will fail in Emacs 24.3.  You need to do
something like this instead:

  M-: (let ((c-standard-font-lock-fontify-region-function 'font-lock-default-fontify-region)) (font-lock-fontify-buffer)) RET

If I do this in Emacs 24.3 and in the current trunk, I do see a
significant slowdown: it takes 18 sec with 24.3, and 72 sec with the
current trunk.

So I think the invocation from hook is not a factor here, which is a
Good Thing, because debugging this will be much simpler ;-)

bug#14886: Fwd: A significant slowdown calling font-lock-fontify-buffer from a hook

[Juanma Barranquero]

Package: emacs
Version: 24.3.50
X-Debbugs-Cc: eliz@gnu.org


Filed.


---------- Forwarded message ----------
From: Eli Zaretskii <eliz@gnu.org>
Date: Tue, Jul 16, 2013 at 8:47 PM
Subject: Re: A significant slowdown calling font-lock-fontify-buffer from a hook
To: Juanma Barranquero <lekktu@gmail.com>
Cc: emacs-devel@gnu.org


> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Tue, 16 Jul 2013 20:26:56 +0200
> Cc: Emacs developers <emacs-devel@gnu.org>
>
> > Is the "calling from a hook" an important part of this issue?
>
> Doing
>
>   emacs -Q src/xdisp.c
>   M-x font-lock-fontify-buffer <RET>
>
> I don't see the slowdown.

First, you need to turn off global-font-lock-mode before visiting
xdisp.c.  Second, if you do turn off global-font-lock-mode, invoking
font-lock-fontify-buffer will fail in Emacs 24.3.  You need to do
something like this instead:

  M-: (let ((c-standard-font-lock-fontify-region-function
'font-lock-default-fontify-region)) (font-lock-fontify-buffer)) RET

If I do this in Emacs 24.3 and in the current trunk, I do see a
significant slowdown: it takes 18 sec with 24.3, and 72 sec with the
current trunk.

So I think the invocation from hook is not a factor here, which is a
Good Thing, because debugging this will be much simpler ;-)

bug#14886: Fwd: A significant slowdown calling font-lock-fontify-buffer from a hook

[Juanma Barranquero]

Running your test from the command line

  emacs.exe -Q -f global-font-lock-mode src\xdisp.c --eval "(let
((c-standard-font-lock-fontify- region-function
'font-lock-default-fontify-region)) (font-lock-fontify-buffer))" -f
kill-emacs

I get quite different times:

 - 24.3, -O0 --enable-checking   ~ 1m 1s.
 - trunk, -O0 --enable-checking=yes,glyph   ~ 1m 40s.
 - trunk, -O2 --enable-checking=yes (no glyph)   ~ 32s.

   J

bug#14886: Fwd: A significant slowdown calling font-lock-fontify-buffer from a hook

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Wed, 17 Jul 2013 05:05:27 +0200
> 
> Running your test from the command line
> 
>   emacs.exe -Q -f global-font-lock-mode src\xdisp.c --eval "(let
> ((c-standard-font-lock-fontify- region-function
> 'font-lock-default-fontify-region)) (font-lock-fontify-buffer))" -f
> kill-emacs
> 
> I get quite different times:
> 
>  - 24.3, -O0 --enable-checking   ~ 1m 1s.
>  - trunk, -O0 --enable-checking=yes,glyph   ~ 1m 40s.
>  - trunk, -O2 --enable-checking=yes (no glyph)   ~ 32s.

Then I guess we have no clear idea what we are talking about.

bug#14886: Fwd: A significant slowdown calling font-lock-fontify-buffer from a hook

[Juanma Barranquero]

On Wed, Jul 17, 2013 at 6:02 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> Then I guess we have no clear idea what we are talking about.

No, but even if not always manitests itself in the same way, the
slowdown is quite real. I've had to remove column-marker-1 from my
hook or wait 30+ seconds to load big C files...

bug#14886: Fwd: A significant slowdown calling font-lock-fontify-buffer from a hook

[Juanma Barranquero]

X-Debbugs-Cc: eggert@cs.ucla.edu


Anyway, in my original report,

  emacs -Q --eval "(add-hook 'prog-mode-hook
#'font-lock-fontify-buffer)" src/xdisp.c -f kill-emacs

an optimized 24.3 build was slower than a non-opt trunk one (both
compiled with gcc 4.7.2).

However, with your test case, non-opt trunk is 30s slower than non-opt
24.3, and optimized trunk needs less than a third of the time of
non-opt trunk (though glyph assertions are enabled, which could affect
the result)...

A shoot in the dark: Could all this be related to Paul's substitution
of many macros by inline functions?

Paul, WDYT?

    Juanma

bug#14886: Fwd: A significant slowdown calling font-lock-fontify-buffer from a hook

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 1092 bytes --]

On 07/17/2013 04:42 AM, Juanma Barranquero wrote:
> Could all this be related to Paul's substitution
> of many macros by inline functions?

Could be.  Did the problem start happening with
trunk bzr 113359?  If so, I would suspect that
it's the recent changes to syntax.c.

But I'm afraid I don't understand what the problem is.
I tried the test case in the bug report:

  src/emacs -Q --eval "(add-hook 'prog-mode-hook #'font-lock-fontify-buffer)" src/xdisp.c -f kill-emacs

I'm running Fedora 17 x86-64 with GCC 4.8.1.
On Emacs 24.3 (configured with --enable-profiling,
but compiled with the default -O2 optimization) this
takes 1.1 s (user + system CPU time).  In the current
trunk (bzr 113441) it takes 50.1 s.

The difference is so large that there must be something
else going on.  Looking at the gprof outputs (attached)
it appears that 24.3 is invoking scan_sexps_forward
only 1628 times, whereas the current trunk is invoking
it 400829 times.  So I assume that most of the performance
difference is something at the Lisp level.  Or perhaps I'm
just not running the correct test case?

[-- Attachment #2: emacs-24.3.gprof.xz --]
[-- Type: application/x-xz, Size: 85860 bytes --]

[-- Attachment #3: emacs-113441.gprof.xz --]
[-- Type: application/x-xz, Size: 95580 bytes --]

bug#14886: Fwd: A significant slowdown calling font-lock-fontify-buffer from a hook

[Juanma Barranquero]

On Wed, Jul 17, 2013 at 2:50 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:

> Could be.  Did the problem start happening with
> trunk bzr 113359?  If so, I would suspect that
> it's the recent changes to syntax.c.

I think the bug I reported started before 113359. I have a checkout of
112954, I'll try bootstrapping it and report back.

> On Emacs 24.3 (configured with --enable-profiling,
> but compiled with the default -O2 optimization) this
> takes 1.1 s (user + system CPU time).  In the current
> trunk (bzr 113441) it takes 50.1 s.

That's similar to what I see: 2s vs 34s approx.

>
> The difference is so large that there must be something
> else going on.  Looking at the gprof outputs (attached)
> it appears that 24.3 is invoking scan_sexps_forward
> only 1628 times, whereas the current trunk is invoking
> it 400829 times.  So I assume that most of the performance
> difference is something at the Lisp level.

Could be.

> Or perhaps I'm
> just not running the correct test case?

What about Eli's test case? What do you see?

   J

bug#14886: Fwd: A significant slowdown calling font-lock-fontify-buffer from a hook

[Paul Eggert]

On 07/17/2013 06:43 AM, Juanma Barranquero wrote:
> What about Eli's test case? What do you see?

Trunk's about the same as Emacs 24.3.
On my platform (configured as in my previous message), running this:

src/emacs -Q -f global-font-lock-mode src/xdisp.c --eval "(let ((c-standard-font-lock-fontify-region-function 'font-lock-default-fontify-region)) (font-lock-fontify-buffer))" -f kill-emacs

took 47.2 s with Emacs 24.3, and 44.7 s on the trunk.

bug#14886: Fwd: A significant slowdown calling font-lock-fontify-buffer from a hook

[Juanma Barranquero]

On Wed, Jul 17, 2013 at 3:43 PM, Juanma Barranquero <lekktu@gmail.com> wrote:

> I think the bug I reported started before 113359. I have a checkout of
> 112954, I'll try bootstrapping it and report back.

Yes, the problem is also visible in revno:112954.

   J

bug#14886: Fwd: A significant slowdown calling font-lock-fontify-buffer from a hook

[Glenn Morris]

It's not clear to me if you are talking about a general problem, or
something specific to CC mode (since that is what your example uses).
Try the 24.3 cc-mode under trunk?

bug#14886: Fwd: A significant slowdown calling font-lock-fontify-buffer from a hook

[Juanma Barranquero]

On Wed, Jul 17, 2013 at 5:57 PM, Glenn Morris <rgm@gnu.org> wrote:

> It's not clear to me if you are talking about a general problem, or
> something specific to CC mode (since that is what your example uses).

That's a good question. Loading a big elisp file does not show the problem.

> Try the 24.3 cc-mode under trunk?

Apparently the problem still persists.

bug#14886: Fwd: A significant slowdown calling font-lock-fontify-buffer from a hook

[Stefan Monnier]

>   src/emacs -Q --eval "(add-hook 'prog-mode-hook
> #'font-lock-fontify-buffer)" src/xdisp.c -f kill-emacs

A run of profiler-start seems to indicate most of the time is spent in
c-find-decl-spots.


        Stefan

bug#14886: Fwd: A significant slowdown calling font-lock-fontify-buffer from a hook

[Juanma Barranquero]

X-Debbugs-CC: acm@muc.de

> A run of profiler-start seems to indicate most of the time is spent in
> c-find-decl-spots.

Alan, could you please take a look at this bug report? The problem
seems specific to editing C files.

Thanks,

   Juanma

bug#14886: Fwd: bug#14886: Fwd: A significant slowdown calling font-lock-fontify-buffer from a hook

[Alan Mackenzie]

Hi, Juanma.

On Tue, Jul 23, 2013 at 01:16:21PM +0200, Juanma Barranquero wrote:
> Alan, I tried to Cc: you from this bug's thread, but apparently
> failed. Could you take a look at this bug, specially at the use case
> that triggered the bug report,

>   emacs -Q --eval "(add-hook 'prog-mode-hook
> #'font-lock-fontify-buffer)" src/xdisp.c -f kill-emacs

When I try this on today's trunk (just updated to rev #113531), I get
28.2s.  The same on Emacs 24.3 aborts with some sort of error in ~1.5s
(although there is no error message visible). 

When I run font-lock-fontify-buffer in either 24.3 or rev #113531 (after
appropriate setting up with global-font-lock-mode, etc.), it takes about
the same 28 seconds.  This is just how long it takes to fontify xdisp.c
without jit-lock.

I don't see the factor 4 slowdown that you did.

> ?

> TIA,

>   Juanma


> ---------- Forwarded message ----------
> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Tue, Jul 23, 2013 at 12:11 AM
> Subject: Re: bug#14886: Fwd: A significant slowdown calling
> font-lock-fontify-buffer from a hook
> To: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Paul Eggert <eggert@cs.ucla.edu>, 14886@debbugs.gnu.org


> X-Debbugs-CC: acm@muc.de

> > A run of profiler-start seems to indicate most of the time is spent in
> > c-find-decl-spots.

This is not unexpected.

> Alan, could you please take a look at this bug report? The problem
> seems specific to editing C files.

> Thanks,

>    Juanma

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#14886: Fwd: bug#14886: Fwd: A significant slowdown calling font-lock-fontify-buffer from a hook

[Juanma Barranquero]

> When I try this on today's trunk (just updated to rev #113531), I get
> 28.2s.  The same on Emacs 24.3 aborts with some sort of error in ~1.5s
> (although there is no error message visible).

In that case, a few conclusions:

- Font-lock-fontify-buffer should not be called from a hook.
- Errors during fontification should be visible. That would have made
clear that there was something wrong with the 24.3 use case.

   J

bug#14886: Fwd: bug#14886: Fwd: A significant slowdown calling font-lock-fontify-buffer from a hook

[Stefan Monnier]

> - Font-lock-fontify-buffer should not be called from a hook.

Font-lock-fontify-buffer is definitely a bad function, since it has
2 different meanings (either "make sure the buffer is fontified" or
"please refontify the buffer").  It should be replaced by two different
functions:
- font-lock-ensure-fontification, which makes sure fontification is
  applied to a particular region (e.g. for use by things like
  htmlfontify or ps-print).
- font-lock-flush-fontification which indicates that the fontification
  for a particular region should be considered out-of-date (e.g. for use
  after calling font-lock-add/remove-keywords).
I don't see why any of those 3 functions shouldn't be called from
a hook, tho.
  
> - Errors during fontification should be visible.  That would have made
> clear that there was something wrong with the 24.3 use case.

Silent errors are bugs.  Please try and find what happens with
the error message.


        Stefan

bug#14886: Fwd: bug#14886: Fwd: A significant slowdown calling font-lock-fontify-buffer from a hook

[Juanma Barranquero]

On Thu, Jul 25, 2013 at 3:24 AM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:

> I don't see why any of those 3 functions shouldn't be called from
> a hook, tho.

Well, it's not that you *must* not call it from a hook, is that if you
call it when starting Emacs, you can have an unacceptable delay. No
one on his/her sane mind wants to wait a long time (almost one minute
in my current setup) to open a file that could be opened in less than
1s.

though

> Silent errors are bugs.  Please try and find what happens with
> the error message.

I think that's more like Alan's ballpark.

   J

bug#14886: Fwd: bug#14886: Fwd: A significant slowdown calling font-lock-fontify-buffer from a hook

[Alan Mackenzie]

Hi, Juanma.

On Thu, Jul 25, 2013 at 08:53:44AM +0200, Juanma Barranquero wrote:
> On Thu, Jul 25, 2013 at 3:24 AM, Stefan Monnier
> <monnier@iro.umontreal.ca> wrote:

> > I don't see why any of those 3 functions shouldn't be called from
> > a hook, tho.

> Well, it's not that you *must* not call it from a hook, is that if you
> call it when starting Emacs, you can have an unacceptable delay. No
> one on his/her sane mind wants to wait a long time (almost one minute
> in my current setup) to open a file that could be opened in less than
> 1s.

Running

emacs -Q --eval "(progn (add-hook 'prog-mode-hook #'font-lock-fontify-buffer) (setq debug-on-error t))" src/xdisp.c

on Emacs 24.3 (I've added a setting of `debug-on-error', and removed the
final `kill-emacs'), goes quickly.  This suggests that the buffer isn't
fully fontified - instead, merely that the first window of it gets
fontified by jit-lock.

> > Silent errors are bugs.  Please try and find what happens with
> > the error message.

The debug-on-error isn't triggered.  My guess that an error occurred
seems to be wrong.

In the trunk, the entire buffer seems to get fontified, taking ~28s on my
machine.  I think the definition of `font-lock-fontify-buffer' has
changed.  Could this change explain the difference in timings you see?

> I think that's more like Alan's ballpark.

I'm not sure I'm getting very far, here.  IIUC, the problem is that the
initial f-l-fontify-buffer is taking around 72s in some circumstances, as
opposed to 18s (on JB's machine).  I can't reproduce the problem.

>    J

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#14886: Fwd: bug#14886: Fwd: A significant slowdown calling font-lock-fontify-buffer from a hook

[Juanma Barranquero]

On Fri, Jul 26, 2013 at 9:44 PM, Alan Mackenzie <acm@muc.de> wrote:

> In the trunk, the entire buffer seems to get fontified, taking ~28s on my
> machine.  I think the definition of `font-lock-fontify-buffer' has
> changed.  Could this change explain the difference in timings you see?

Yes, I suppose so.

> I'm not sure I'm getting very far, here.  IIUC, the problem is that the
> initial f-l-fontify-buffer is taking around 72s in some circumstances, as
> opposed to 18s (on JB's machine).  I can't reproduce the problem.

Sorry, I don't understand. The bug is not that it takes 18s or 72s, is
that it goes from less than two seconds (in 24.3) to tens of seconds
(in trunk). Do you see that problem or don't you?

    Juanma

bug#14886: Fwd: bug#14886: Fwd: A significant slowdown calling font-lock-fontify-buffer from a hook

[Alan Mackenzie]

Hi, Juanma.

On Fri, Jul 26, 2013 at 11:32:03PM +0200, Juanma Barranquero wrote:
> On Fri, Jul 26, 2013 at 9:44 PM, Alan Mackenzie <acm@muc.de> wrote:

> > In the trunk, the entire buffer seems to get fontified, taking ~28s on my
> > machine.  I think the definition of `font-lock-fontify-buffer' has
> > changed.  Could this change explain the difference in timings you see?

> Yes, I suppose so.

> > I'm not sure I'm getting very far, here.  IIUC, the problem is that the
> > initial f-l-fontify-buffer is taking around 72s in some circumstances, as
> > opposed to 18s (on JB's machine).  I can't reproduce the problem.

> Sorry, I don't understand. The bug is not that it takes 18s or 72s, is
> that it goes from less than two seconds (in 24.3) to tens of seconds
> (in trunk). Do you see that problem or don't you?

I see the phenomenon, yes, but I'm not sure it counts as a problem.  To
completely fontify the xdisp.c buffer takes 28s, or perhaps 18s on a very
fast machine.  xdisp.c is ~30,000 lines.  It does not take two seconds to
fontify on any ordinary hardware.

On Emacs 24.3, I'm convinced that a full fontification is _not_ taking
place - merely the fontification by jit-lock of the visible window.  On
the trunk the full fontification is getting done.

I've tried a brief ediff between the font-lock files in 24.3 and trunk,
but haven't spotted the difference yet in font-lock-fontify-buffer which
I suspect is there.  Stefan?

>     Juanma

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#14886: Fwd: bug#14886: Fwd: A significant slowdown calling font-lock-fontify-buffer from a hook

[Juanma Barranquero]

On Sat, Jul 27, 2013 at 11:35 AM, Alan Mackenzie <acm@muc.de> wrote:

> I see the phenomenon, yes, but I'm not sure it counts as a problem.

Then, please do not waste more time on this. We can dismiss it as a
bug on column-marker-mode, or on my using it from a hook.

Thanks,

    Juanma

bug#14886: Fwd: bug#14886: Fwd: A significant slowdown calling font-lock-fontify-buffer from a hook

[martin rudalics]

 > I've tried a brief ediff between the font-lock files in 24.3 and trunk,
 > but haven't spotted the difference yet in font-lock-fontify-buffer which
 > I suspect is there.

Why should there be any difference?  The value that differs is that of
`font-lock-fontify-buffer-function'.  Calling `font-lock-fontify-buffer'
from prog-mode does `font-lock-default-fontify-buffer'.  Calling it from
c-mode does `jit-lock-refontify'.  Or what am I missing?

martin

bug#14886: Fwd: bug#14886: Fwd: A significant slowdown calling font-lock-fontify-buffer from a hook

[Stefan Monnier]

>> I've tried a brief ediff between the font-lock files in 24.3 and trunk,
>> but haven't spotted the difference yet in font-lock-fontify-buffer which
>> I suspect is there.

> Why should there be any difference?  The value that differs is that of
> `font-lock-fontify-buffer-function'.  Calling `font-lock-fontify-buffer'
> from prog-mode does `font-lock-default-fontify-buffer'.  Calling it from
> c-mode does `jit-lock-refontify'.  Or what am I missing?

So it's back to the problem of font-lock-fontify-buffer meaning two
different things.  Could someone look into providing
font-lock-ensure-fontification and font-lock-mark-for-refontification,
and mark font-lock-fontify-buffer obsolete?


        Stefan

bug#14886: Fwd: bug#14886: Fwd: A significant slowdown calling font-lock-fontify-buffer from a hook

[Alan Mackenzie]

Hello, Martin.

On Sat, Jul 27, 2013 at 12:20:38PM +0200, martin rudalics wrote:
>  > I've tried a brief ediff between the font-lock files in 24.3 and trunk,
>  > but haven't spotted the difference yet in font-lock-fontify-buffer which
>  > I suspect is there.

I am calling:

emacs -Q --eval "(progn (add-hook 'prog-mode-hook #'font-lock-fontify-buffer) (setq debug-on-error t))" ~/emacs/emacs.bzr/trunk/src/xdisp.c

using both emacs 24.3 and the trunk.  In 24.3, the processing is
immediate (~2s), whereas in the trunk it takes ~28s.

> Why should there be any difference?  The value that differs is that of
> `font-lock-fontify-buffer-function'.

In both 24.3 and trunk, `font-lock-fontify-buffer-function' ends up with
the value `jit-lock-refontify'.

> Calling `font-lock-fontify-buffer' from prog-mode does
> `font-lock-default-fontify-buffer'.  Calling it from c-mode does
> `jit-lock-refontify'.  Or what am I missing?

I don't understand what you mean by "from c-mode" and "from prog-mode".
Are you saying that that has somehow changed between 24.3 and the trunk?

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#14886: Fwd: bug#14886: Fwd: A significant slowdown calling font-lock-fontify-buffer from a hook

[Lars Ingebrigtsen]

Alan Mackenzie <acm@muc.de> writes:

> I am calling:
>
> emacs -Q --eval "(progn (add-hook 'prog-mode-hook #'font-lock-fontify-buffer) (setq debug-on-error t))" ~/emacs/emacs.bzr/trunk/src/xdisp.c
>
> using both emacs 24.3 and the trunk.  In 24.3, the processing is
> immediate (~2s), whereas in the trunk it takes ~28s.

This function still takes a long time when called from the hook, but in
2014 the function was marked interactive-only, so I don't think this is
something to be fixed -- at least not at this point.  So I'm closing the
bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#14886: Fwd: A significant slowdown calling font-lock-fontify-buffer from a hook

[Eli Zaretskii]

> X-Spam-Status: No, score=-101.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,
> 	T_DKIM_INVALID,USER_IN_WHITELIST autolearn=disabled version=3.3.2
> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Wed, 17 Jul 2013 11:04:18 +0200
> Cc: 14886@debbugs.gnu.org
> 
> On Wed, Jul 17, 2013 at 6:02 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > Then I guess we have no clear idea what we are talking about.
> 
> No, but even if not always manitests itself in the same way, the
> slowdown is quite real. I've had to remove column-marker-1 from my
> hook or wait 30+ seconds to load big C files...

Efficient debugging of a problem needs a simple test case that you can
easily run and modify to test various hypotheses.  If we must always
run this from weird --eval arguments on the command line, and on top
of that call fontification from an obscure mode hook, the debugging
will be anything but easy.

I suggest to try to simplify the test case.

bug#14886: Fwd: A significant slowdown calling font-lock-fontify-buffer from a hook

[Juanma Barranquero]

On Wed, Jul 17, 2013 at 5:04 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> If we must always
> run this from weird --eval arguments on the command line

Using --eval from the command line is not required, just makes timing
it all easier. But if you want a reproducible case without eval:

  ;; .emacs starts here
  (add-hook 'prog-mode-hook 'font-lock-fontify-buffer)
  ;; .emacs ends here

  emacs [/path/to/]xdisp.c

That's it. I don't know how to make it simpler.

> and on top
> of that call fontification from an obscure mode hook

prog-mode-hook isn't "obscure", We've spent time making all
programming modes derive from prog-mode, so running things on it is
nothing strange.

Also, I do not choose where I will hit a bug :-)

   J