* 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 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
[parent not found: <CAAeL0STtrBnWTbc0FSPn6XHArcDtxHwzNVaijvyG5bVKMLRo+w@mail.gmail.com>]
* 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
* 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
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).