GNU bug report logs -
#14886
Slowdown on font-lock-fontify-buffer
Previous Next
Reported by: Juanma Barranquero <lekktu <at> gmail.com>
Date: Tue, 16 Jul 2013 23:05:02 UTC
Severity: normal
Found in version 24.3.50
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
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 <at> 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).
This bug report was last modified 5 years and 210 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.