GNU bug report logs - #25706
26.0.50; Slow C file fontification

Previous Next

Full log

Message #134 received at 25706 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Ravine Var <ravine.var <at> gmail.com>
Cc: Mattias Engdegård <mattiase <at> acm.org>,
 Lars Ingebrigtsen <larsi <at> gnus.org>, 25706 <at> debbugs.gnu.org
Subject: Re: bug#25706: 26.0.50; Slow C file fontification
Date: Sat, 12 Dec 2020 15:34:33 +0000

Hello, Ravine.

On Fri, Dec 11, 2020 at 16:25:20 +0530, Ravine Var wrote:
> Alan Mackenzie <acm <at> muc.de> writes:
> > To fix this, can I ask you, please, to try adding the following patch to
> > your already patched software, and let me know if it helps at all.  If
> > it does, that's great, if not, could I ask you to do another profile for
> > me on the less powerful machine, say by opening the buffer, starting the
> > profiler, then moving to the middle of the buffer with C-u 5 M->.  This
> > may take some time to profile.  Thanks!

> Doing C-u 5 M-> just jumps to the middle immediately. The problem
> happens when the file is opened and I start scrolling with C-v.
> With the new patch, things are still bad - emacs freezes almost
> instantly.

I've had a good look at your latest profile result.  There doesn't seem
to be any further untoward looping of low-level functions.  So I'm not
sure what more to fix, other than....

Have you got the option fast-but-imprecise-scrolling set (or customized)
to non-nil?  If not, could I suggest you try it.  It's effect is to stop
Emacs fontifying every screen it scrolls over, instead only fontifying
screens when it's got no more input commands waiting.  This speeds
things up quite a bit on a slower machine.

> I tested with 3 patches applied from messages 35, 95 and 128.

> Here's the profile with emacs -Q :

> https://gist.github.com/ravine-var/48b3e1469ac5a7f3c3df8d6d9313661a

Thanks!  There appear to be about 8 seconds worth of profile data there.
How many screenfulls, approximately, did you actually scroll over in
that time?  Or, rather than answering that question, could I get you to
try another timing test?

Please put the following code into your *scratch* buffer (it's the same
code I've posted before) and evaluate it:

    (defmacro time-it (&rest forms)
      "Time the running of a sequence of forms using `float-time'.
    Call like this: \"M-: (time-it (foo ...) (bar ...) ...)\"."
      `(let ((start (float-time)))
        ,@forms
        (- (float-time) start)))

Then please load osprey_reg_map_macro.h freshly into a buffer, and type
(or cut and paste) the following into M-:

    (time-it (let ((n 10)) (while (> n 0) (scroll-up) (sit-for 0) (setq n (1- n)))))

What is the reported timing for scrolling these ten screens?

Thanks!

-- 
Alan Mackenzie (Nuremberg, Germany).

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.