* bug#14886: Fwd: A significant slowdown calling font-lock-fontify-buffer from a hook
[not found] ` <83ehay2vgw.fsf@gnu.org>
@ 2013-07-16 23:03 ` Juanma Barranquero
2013-07-17 3:05 ` Juanma Barranquero
0 siblings, 1 reply; 27+ messages in thread
From: Juanma Barranquero @ 2013-07-16 23:03 UTC (permalink / raw)
To: 14886
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 ;-)
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#14886: Fwd: A significant slowdown calling font-lock-fontify-buffer from a hook
2013-07-16 23:03 ` bug#14886: Fwd: A significant slowdown calling font-lock-fontify-buffer from a hook Juanma Barranquero
@ 2013-07-17 3:05 ` Juanma Barranquero
2013-07-17 4:02 ` Eli Zaretskii
0 siblings, 1 reply; 27+ messages in thread
From: Juanma Barranquero @ 2013-07-17 3:05 UTC (permalink / raw)
To: 14886
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#14886: Fwd: A significant slowdown calling font-lock-fontify-buffer from a hook
2013-07-17 3:05 ` Juanma Barranquero
@ 2013-07-17 4:02 ` Eli Zaretskii
2013-07-17 9:04 ` Juanma Barranquero
0 siblings, 1 reply; 27+ messages in thread
From: Eli Zaretskii @ 2013-07-17 4:02 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: 14886
> 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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#14886: Fwd: A significant slowdown calling font-lock-fontify-buffer from a hook
2013-07-17 4:02 ` Eli Zaretskii
@ 2013-07-17 9:04 ` Juanma Barranquero
2013-07-17 11:42 ` Juanma Barranquero
2013-07-17 15:04 ` Eli Zaretskii
0 siblings, 2 replies; 27+ messages in thread
From: Juanma Barranquero @ 2013-07-17 9:04 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 14886
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...
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#14886: Fwd: A significant slowdown calling font-lock-fontify-buffer from a hook
2013-07-17 9:04 ` Juanma Barranquero
@ 2013-07-17 11:42 ` Juanma Barranquero
2013-07-17 12:50 ` Paul Eggert
2013-07-17 15:04 ` Eli Zaretskii
1 sibling, 1 reply; 27+ messages in thread
From: Juanma Barranquero @ 2013-07-17 11:42 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: eggert, 14886
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#14886: Fwd: A significant slowdown calling font-lock-fontify-buffer from a hook
2013-07-17 11:42 ` Juanma Barranquero
@ 2013-07-17 12:50 ` Paul Eggert
2013-07-17 13:43 ` Juanma Barranquero
2013-07-22 4:20 ` Stefan Monnier
0 siblings, 2 replies; 27+ messages in thread
From: Paul Eggert @ 2013-07-17 12:50 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: 14886
[-- 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 --]
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#14886: Fwd: A significant slowdown calling font-lock-fontify-buffer from a hook
2013-07-17 12:50 ` Paul Eggert
@ 2013-07-17 13:43 ` Juanma Barranquero
2013-07-17 13:59 ` Paul Eggert
` (2 more replies)
2013-07-22 4:20 ` Stefan Monnier
1 sibling, 3 replies; 27+ messages in thread
From: Juanma Barranquero @ 2013-07-17 13:43 UTC (permalink / raw)
To: Paul Eggert; +Cc: 14886
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#14886: Fwd: A significant slowdown calling font-lock-fontify-buffer from a hook
2013-07-17 13:43 ` Juanma Barranquero
@ 2013-07-17 13:59 ` Paul Eggert
2013-07-17 15:19 ` Juanma Barranquero
2013-07-17 15:57 ` Glenn Morris
2 siblings, 0 replies; 27+ messages in thread
From: Paul Eggert @ 2013-07-17 13:59 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: 14886
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#14886: Fwd: A significant slowdown calling font-lock-fontify-buffer from a hook
2013-07-17 9:04 ` Juanma Barranquero
2013-07-17 11:42 ` Juanma Barranquero
@ 2013-07-17 15:04 ` Eli Zaretskii
2013-07-17 15:16 ` Juanma Barranquero
1 sibling, 1 reply; 27+ messages in thread
From: Eli Zaretskii @ 2013-07-17 15:04 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: 14886
> 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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#14886: Fwd: A significant slowdown calling font-lock-fontify-buffer from a hook
2013-07-17 15:04 ` Eli Zaretskii
@ 2013-07-17 15:16 ` Juanma Barranquero
0 siblings, 0 replies; 27+ messages in thread
From: Juanma Barranquero @ 2013-07-17 15:16 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 14886
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#14886: Fwd: A significant slowdown calling font-lock-fontify-buffer from a hook
2013-07-17 13:43 ` Juanma Barranquero
2013-07-17 13:59 ` Paul Eggert
@ 2013-07-17 15:19 ` Juanma Barranquero
2013-07-17 15:57 ` Glenn Morris
2 siblings, 0 replies; 27+ messages in thread
From: Juanma Barranquero @ 2013-07-17 15:19 UTC (permalink / raw)
To: Paul Eggert; +Cc: 14886
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#14886: Fwd: A significant slowdown calling font-lock-fontify-buffer from a hook
2013-07-17 13:43 ` Juanma Barranquero
2013-07-17 13:59 ` Paul Eggert
2013-07-17 15:19 ` Juanma Barranquero
@ 2013-07-17 15:57 ` Glenn Morris
2013-07-17 16:56 ` Juanma Barranquero
2 siblings, 1 reply; 27+ messages in thread
From: Glenn Morris @ 2013-07-17 15:57 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: Paul Eggert, 14886
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?
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#14886: Fwd: A significant slowdown calling font-lock-fontify-buffer from a hook
2013-07-17 15:57 ` Glenn Morris
@ 2013-07-17 16:56 ` Juanma Barranquero
0 siblings, 0 replies; 27+ messages in thread
From: Juanma Barranquero @ 2013-07-17 16:56 UTC (permalink / raw)
To: Glenn Morris; +Cc: Paul Eggert, 14886
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#14886: Fwd: A significant slowdown calling font-lock-fontify-buffer from a hook
2013-07-17 12:50 ` Paul Eggert
2013-07-17 13:43 ` Juanma Barranquero
@ 2013-07-22 4:20 ` Stefan Monnier
2013-07-22 22:11 ` Juanma Barranquero
1 sibling, 1 reply; 27+ messages in thread
From: Stefan Monnier @ 2013-07-22 4:20 UTC (permalink / raw)
To: Paul Eggert; +Cc: Juanma Barranquero, 14886
> 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
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#14886: Fwd: A significant slowdown calling font-lock-fontify-buffer from a hook
2013-07-22 4:20 ` Stefan Monnier
@ 2013-07-22 22:11 ` Juanma Barranquero
[not found] ` <CAAeL0STtrBnWTbc0FSPn6XHArcDtxHwzNVaijvyG5bVKMLRo+w@mail.gmail.com>
0 siblings, 1 reply; 27+ messages in thread
From: Juanma Barranquero @ 2013-07-22 22:11 UTC (permalink / raw)
To: Stefan Monnier; +Cc: acm, Paul Eggert, 14886
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#14886: Fwd: bug#14886: Fwd: A significant slowdown calling font-lock-fontify-buffer from a hook
[not found] ` <CAAeL0STtrBnWTbc0FSPn6XHArcDtxHwzNVaijvyG5bVKMLRo+w@mail.gmail.com>
@ 2013-07-24 19:30 ` Alan Mackenzie
2013-07-24 21:29 ` Juanma Barranquero
0 siblings, 1 reply; 27+ messages in thread
From: Alan Mackenzie @ 2013-07-24 19:30 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: Paul Eggert, 14886
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).
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#14886: Fwd: bug#14886: Fwd: A significant slowdown calling font-lock-fontify-buffer from a hook
2013-07-24 19:30 ` bug#14886: Fwd: " Alan Mackenzie
@ 2013-07-24 21:29 ` Juanma Barranquero
2013-07-25 1:24 ` Stefan Monnier
0 siblings, 1 reply; 27+ messages in thread
From: Juanma Barranquero @ 2013-07-24 21:29 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: Paul Eggert, 14886
> 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
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#14886: Fwd: bug#14886: Fwd: A significant slowdown calling font-lock-fontify-buffer from a hook
2013-07-24 21:29 ` Juanma Barranquero
@ 2013-07-25 1:24 ` Stefan Monnier
2013-07-25 6:53 ` Juanma Barranquero
0 siblings, 1 reply; 27+ messages in thread
From: Stefan Monnier @ 2013-07-25 1:24 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: Alan Mackenzie, Paul Eggert, 14886
> - 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
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#14886: Fwd: bug#14886: Fwd: A significant slowdown calling font-lock-fontify-buffer from a hook
2013-07-25 1:24 ` Stefan Monnier
@ 2013-07-25 6:53 ` Juanma Barranquero
2013-07-26 19:44 ` Alan Mackenzie
0 siblings, 1 reply; 27+ messages in thread
From: Juanma Barranquero @ 2013-07-25 6:53 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Alan Mackenzie, Paul Eggert, 14886
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#14886: Fwd: bug#14886: Fwd: A significant slowdown calling font-lock-fontify-buffer from a hook
2013-07-25 6:53 ` Juanma Barranquero
@ 2013-07-26 19:44 ` Alan Mackenzie
2013-07-26 21:32 ` Juanma Barranquero
0 siblings, 1 reply; 27+ messages in thread
From: Alan Mackenzie @ 2013-07-26 19:44 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: Paul Eggert, 14886
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).
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#14886: Fwd: bug#14886: Fwd: A significant slowdown calling font-lock-fontify-buffer from a hook
2013-07-26 19:44 ` Alan Mackenzie
@ 2013-07-26 21:32 ` Juanma Barranquero
2013-07-27 9:35 ` Alan Mackenzie
0 siblings, 1 reply; 27+ messages in thread
From: Juanma Barranquero @ 2013-07-26 21:32 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: Paul Eggert, 14886
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#14886: Fwd: bug#14886: Fwd: A significant slowdown calling font-lock-fontify-buffer from a hook
2013-07-26 21:32 ` Juanma Barranquero
@ 2013-07-27 9:35 ` Alan Mackenzie
2013-07-27 10:10 ` Juanma Barranquero
2013-07-27 10:20 ` martin rudalics
0 siblings, 2 replies; 27+ messages in thread
From: Alan Mackenzie @ 2013-07-27 9:35 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: Paul Eggert, 14886
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).
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#14886: Fwd: bug#14886: Fwd: A significant slowdown calling font-lock-fontify-buffer from a hook
2013-07-27 9:35 ` Alan Mackenzie
@ 2013-07-27 10:10 ` Juanma Barranquero
2013-07-27 10:20 ` martin rudalics
1 sibling, 0 replies; 27+ messages in thread
From: Juanma Barranquero @ 2013-07-27 10:10 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: Paul Eggert, 14886
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#14886: Fwd: bug#14886: Fwd: A significant slowdown calling font-lock-fontify-buffer from a hook
2013-07-27 9:35 ` Alan Mackenzie
2013-07-27 10:10 ` Juanma Barranquero
@ 2013-07-27 10:20 ` martin rudalics
2013-07-27 14:03 ` Stefan Monnier
2013-07-28 9:58 ` Alan Mackenzie
1 sibling, 2 replies; 27+ messages in thread
From: martin rudalics @ 2013-07-27 10:20 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: Juanma Barranquero, Paul Eggert, 14886
> 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
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#14886: Fwd: bug#14886: Fwd: A significant slowdown calling font-lock-fontify-buffer from a hook
2013-07-27 10:20 ` martin rudalics
@ 2013-07-27 14:03 ` Stefan Monnier
2013-07-28 9:58 ` Alan Mackenzie
1 sibling, 0 replies; 27+ messages in thread
From: Stefan Monnier @ 2013-07-27 14:03 UTC (permalink / raw)
To: martin rudalics; +Cc: Alan Mackenzie, Paul Eggert, 14886, Juanma Barranquero
>> 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
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#14886: Fwd: bug#14886: Fwd: A significant slowdown calling font-lock-fontify-buffer from a hook
2013-07-27 10:20 ` martin rudalics
2013-07-27 14:03 ` Stefan Monnier
@ 2013-07-28 9:58 ` Alan Mackenzie
2019-10-30 12:52 ` Lars Ingebrigtsen
1 sibling, 1 reply; 27+ messages in thread
From: Alan Mackenzie @ 2013-07-28 9:58 UTC (permalink / raw)
To: martin rudalics; +Cc: Juanma Barranquero, Paul Eggert, 14886
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).
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#14886: Fwd: bug#14886: Fwd: A significant slowdown calling font-lock-fontify-buffer from a hook
2013-07-28 9:58 ` Alan Mackenzie
@ 2019-10-30 12:52 ` Lars Ingebrigtsen
0 siblings, 0 replies; 27+ messages in thread
From: Lars Ingebrigtsen @ 2019-10-30 12:52 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: Paul Eggert, 14886, Juanma Barranquero
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
^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2019-10-30 12:52 UTC | newest]
Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <CAAeL0SSqSShXtsnqfkiF3H9n+OxYwuJ4yi6ci=wwfdnb8JpqcQ@mail.gmail.com>
[not found] ` <83ip0a2xlb.fsf@gnu.org>
[not found] ` <CAAeL0SQXebErPFigy5q03fPprJN+g6C=itt4as8vJ7JGMMDL7Q@mail.gmail.com>
[not found] ` <83ehay2vgw.fsf@gnu.org>
2013-07-16 23:03 ` bug#14886: Fwd: A significant slowdown calling font-lock-fontify-buffer from a hook Juanma Barranquero
2013-07-17 3:05 ` Juanma Barranquero
2013-07-17 4:02 ` Eli Zaretskii
2013-07-17 9:04 ` Juanma Barranquero
2013-07-17 11:42 ` Juanma Barranquero
2013-07-17 12:50 ` Paul Eggert
2013-07-17 13:43 ` Juanma Barranquero
2013-07-17 13:59 ` Paul Eggert
2013-07-17 15:19 ` Juanma Barranquero
2013-07-17 15:57 ` Glenn Morris
2013-07-17 16:56 ` Juanma Barranquero
2013-07-22 4:20 ` Stefan Monnier
2013-07-22 22:11 ` Juanma Barranquero
[not found] ` <CAAeL0STtrBnWTbc0FSPn6XHArcDtxHwzNVaijvyG5bVKMLRo+w@mail.gmail.com>
2013-07-24 19:30 ` bug#14886: Fwd: " Alan Mackenzie
2013-07-24 21:29 ` Juanma Barranquero
2013-07-25 1:24 ` Stefan Monnier
2013-07-25 6:53 ` Juanma Barranquero
2013-07-26 19:44 ` Alan Mackenzie
2013-07-26 21:32 ` Juanma Barranquero
2013-07-27 9:35 ` Alan Mackenzie
2013-07-27 10:10 ` Juanma Barranquero
2013-07-27 10:20 ` martin rudalics
2013-07-27 14:03 ` Stefan Monnier
2013-07-28 9:58 ` Alan Mackenzie
2019-10-30 12:52 ` Lars Ingebrigtsen
2013-07-17 15:04 ` Eli Zaretskii
2013-07-17 15:16 ` Juanma Barranquero
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).