bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Alan Mackenzie]

Hello, Emacs.

In the .dir-locals in our source tree, the entry for C Mode enables
bug-reference-prog-mode.

This minor mode makes direct use of jit-lock-functions, the low level
hook which connects jit-lock with font-lock.

The jit-lock functions have a feature whereby, when fontifying a
500-byte chunk, font-lock-fontify-region notifies jit-lock of the actual
region just fontified, which is typically bigger than the suggested 500
bytes.  This enables jit lock to proceed through the buffer without
fontifying the same text twice.

However, this mechanism is rendered ineffective if a second function is
add-hook'd onto jit-lock-functions.  Maybe this could be fixed, though
it looks difficult.

When applied to C Mode, bug-reference-prog-mode slows down a scroll from
point-min to point-max by around 7%.

Just how useful is bug-reference-prog-mode?  Is it really worth this 7%
slowdown?

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Eli Zaretskii]

> Date: Wed, 1 Sep 2021 17:33:06 +0000
> From: Alan Mackenzie <acm@muc.de>
> 
> When applied to C Mode, bug-reference-prog-mode slows down a scroll from
> point-min to point-max by around 7%.
> 
> Just how useful is bug-reference-prog-mode?  Is it really worth this 7%
> slowdown?

It is marginally useful, but 7% slowdown is too heavy a price, IMO.
This should be fixed.

(I thought that the code in jit-lock.el already handled this case by
computing a kind-of "maximum" out of all the return values of
jit-lock-functions, and treating a nil return value as expected, but
maybe my reading of the code was incorrect?)

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Alan Mackenzie]

Hello, Eli.

On Wed, Sep 01, 2021 at 20:44:23 +0300, Eli Zaretskii wrote:
> > Date: Wed, 1 Sep 2021 17:33:06 +0000
> > From: Alan Mackenzie <acm@muc.de>

> > When applied to C Mode, bug-reference-prog-mode slows down a scroll from
> > point-min to point-max by around 7%.

> > Just how useful is bug-reference-prog-mode?  Is it really worth this 7%
> > slowdown?

> It is marginally useful, but 7% slowdown is too heavy a price, IMO.
> This should be fixed.

I agree.

> (I thought that the code in jit-lock.el already handled this case by
> computing a kind-of "maximum" out of all the return values of
> jit-lock-functions, and treating a nil return value as expected, but
> maybe my reading of the code was incorrect?)

I think it rather uses the "minimum", i.e. the region common to all the
return values from the jit-lock-functions.  If one of these values is nil
(as is the case here), that boils down to exactly the 500-byte chunk.

The comments in jit-lock.el say that this happens, and half-propose a
mechanism for fixing it.  It doesn't look straightforward to fix.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Eli Zaretskii]

> Date: Wed, 1 Sep 2021 17:55:46 +0000
> Cc: emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > (I thought that the code in jit-lock.el already handled this case by
> > computing a kind-of "maximum" out of all the return values of
> > jit-lock-functions, and treating a nil return value as expected, but
> > maybe my reading of the code was incorrect?)
> 
> I think it rather uses the "minimum", i.e. the region common to all the
> return values from the jit-lock-functions.  If one of these values is nil
> (as is the case here), that boils down to exactly the 500-byte chunk.

Then I think the easiest fix is to get bug-reference-prog-mode return
a suitable value, or wrap it in a function that would.  Every function
that puts itself on jit-lock-functions without actually fontifying
anything should return BOB..EOB as the region it fontified, right?

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Alan Mackenzie]

Hello, Eli.

On Wed, Sep 01, 2021 at 21:01:55 +0300, Eli Zaretskii wrote:
> > Date: Wed, 1 Sep 2021 17:55:46 +0000
> > Cc: emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > (I thought that the code in jit-lock.el already handled this case by
> > > computing a kind-of "maximum" out of all the return values of
> > > jit-lock-functions, and treating a nil return value as expected, but
> > > maybe my reading of the code was incorrect?)

> > I think it rather uses the "minimum", i.e. the region common to all the
> > return values from the jit-lock-functions.  If one of these values is nil
> > (as is the case here), that boils down to exactly the 500-byte chunk.

> Then I think the easiest fix is to get bug-reference-prog-mode return
> a suitable value, or wrap it in a function that would.  Every function
> that puts itself on jit-lock-functions without actually fontifying
> anything should return BOB..EOB as the region it fontified, right?

I'm not sure that's the right fix.  If font-lock mode were disabled, say,
bug-reference-fontify would be the only function on jit-lock-functions.
Then it would fontify the first chunk at BOB, return (jit-lock-bounds .
(BOB . EOB)), which would cause `fontified' to be set on the entire
buffer, and no further chunks would get fontified at all.

The mechanism with `jit-lock-bounds' in jit-lock.el is a good idea, but
somehow it's not quite optimal at the moment.  Maybe it could be
improved.  For example, if the first jit-lock-functions element returns
(... (new-BEG .  new-END)) we might be able to supply new-BEG, new-END as
the arguments to the second element.  Or something like that.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Eli Zaretskii]

> Date: Wed, 1 Sep 2021 18:20:25 +0000
> Cc: emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > Then I think the easiest fix is to get bug-reference-prog-mode return
> > a suitable value, or wrap it in a function that would.  Every function
> > that puts itself on jit-lock-functions without actually fontifying
> > anything should return BOB..EOB as the region it fontified, right?
> 
> I'm not sure that's the right fix.  If font-lock mode were disabled, say,
> bug-reference-fontify would be the only function on jit-lock-functions.

But that never happens, does it?

Or if we want to be holier than the Pope, bug-reference-fontify could
check if it's the only function on the list, and then change its
return value accordingly.

> The mechanism with `jit-lock-bounds' in jit-lock.el is a good idea, but
> somehow it's not quite optimal at the moment.

It was designed for functions that actually fontify something.  We
need to either extend it for functions that don't, or change those
functions to pretend they do, but in a way that doesn't disrupt
jit-lock-bounds.

> For example, if the first jit-lock-functions element returns
> (... (new-BEG .  new-END)) we might be able to supply new-BEG, new-END as
> the arguments to the second element.  Or something like that.

I think it's too late to change the protocol, since it was in use for
too long.

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Alan Mackenzie]

Hello, Eli.

On Wed, Sep 01, 2021 at 21:28:49 +0300, Eli Zaretskii wrote:
> > Date: Wed, 1 Sep 2021 18:20:25 +0000
> > Cc: emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > Then I think the easiest fix is to get bug-reference-prog-mode
> > > return a suitable value, or wrap it in a function that would.
> > > Every function that puts itself on jit-lock-functions without
> > > actually fontifying anything should return BOB..EOB as the region
> > > it fontified, right?

> > I'm not sure that's the right fix.  If font-lock mode were disabled,
> > say, bug-reference-fontify would be the only function on
> > jit-lock-functions.

> But that never happens, does it?

I just did M-x font-lock-mode.  bug-reference-fontify was the only thing
left in jit-lock-functions.

> Or if we want to be holier than the Pope, bug-reference-fontify could
> check if it's the only function on the list, and then change its
> return value accordingly.

That's horrible!  ;-)  There might be two such functions that each
returns nil, and so on.

> > The mechanism with `jit-lock-bounds' in jit-lock.el is a good idea,
> > but somehow it's not quite optimal at the moment.

> It was designed for functions that actually fontify something.  We
> need to either extend it for functions that don't, or change those
> functions to pretend they do, but in a way that doesn't disrupt
> jit-lock-bounds.

I'm more in favour of enhancing the mechanism in jit-lock.el.  The
protocol to the fontifying functions is very stable, robust, and simple.

> > For example, if the first jit-lock-functions element returns
> > (... (new-BEG .  new-END)) we might be able to supply new-BEG, new-END as
> > the arguments to the second element.  Or something like that.

> I think it's too late to change the protocol, since it was in use for
> too long.

Does that change the protocol?  It merely gives a different chunk to the
later functions.  Given that they're expecting a sequence of contiguous
chunks in successive invocations, why does it matter if we pass (501
1050), (1050 2000), .... as successive argument regions rather than (501
1001), (1001 1501)?

There seem to be two types of jit-lock-functions elements.  The first,
which uses the `jit-lock-bounds' mechanism and the second which returns
a random value like nil.  I'm only aware of font-lock-fontify-region in
the first type.

So all we need to do is make sure that f-l-fontify-region is the first
function in jit-lock-functions.  All we need for that is an &optional
parameter to jit-lock-register meaning "put this function first in the
list".  Maybe.

Perhaps Stefan will say something about this problem.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Stefan Monnier]

> However, this mechanism is rendered ineffective if a second function is
> add-hook'd onto jit-lock-functions.  Maybe this could be fixed, though
> it looks difficult.

I think we can "easily" handle this specific case if the
`bug-reference-prog-mode` function is added to the end of the hook
rather than to its beginning and use a patch along the lines of the
one below.

I don't know if it would make any difference to the 7% figure.


        Stefan


diff --git a/lisp/jit-lock.el b/lisp/jit-lock.el
index a905936b6b9..14d09c979b9 100644
--- a/lisp/jit-lock.el
+++ b/lisp/jit-lock.el
@@ -390,7 +390,7 @@ jit-lock--run-functions
      'jit-lock-functions
      (lambda (fun)
        (pcase-let*
-           ((res (funcall fun beg end))
+           ((res (funcall fun (or tight-beg beg) (tight-end end)))
             (`(,this-beg . ,this-end)
              (if (eq (car-safe res) 'jit-lock-bounds)
                  (cdr res) (cons beg end))))

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Wed, 01 Sep 2021 16:59:02 -0400
> 
> > However, this mechanism is rendered ineffective if a second function is
> > add-hook'd onto jit-lock-functions.  Maybe this could be fixed, though
> > it looks difficult.
> 
> I think we can "easily" handle this specific case if the
> `bug-reference-prog-mode` function is added to the end of the hook
> rather than to its beginning and use a patch along the lines of the
> one below.

Thanks, but I think we want a comment there explaining why we do this
and mentioning the order of the functions.

Also, it isn't clear to me whether this will work with more than 2
functions, because the order of the functions is not completely
controlled by a single Lisp program.

> I don't know if it would make any difference to the 7% figure.

I'm sure Alan will tell us.

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Alan Mackenzie]

Hello, Stefan.

On Wed, Sep 01, 2021 at 16:59:02 -0400, Stefan Monnier wrote:
> > However, this mechanism is rendered ineffective if a second function
> > is add-hook'd onto jit-lock-functions.  Maybe this could be fixed,
> > though it looks difficult.

> I think we can "easily" handle this specific case if the
> `bug-reference-prog-mode` function is added to the end of the hook
> rather than to its beginning and use a patch along the lines of the
> one below.

Yes.  How about an optional parameter to jit-lock-register meaning "put
this function at the beginning of jit-lock-functions", with the default
meaning put the function at the end?

I haven't tried it, but I don't think the patch below is quite enough.
I think it needs a (setq beg (min tight-beg beg)), or something like
that, to prevent TIGHT-BEG being set back to the original value of BEG
in the body of jit-lock--run-functions.

> I don't know if it would make any difference to the 7% figure.

I'm sure it would.  That slow down comes from Jit Lock fontifying the
statement straddling a jit chunk border twice.

>         Stefan


> diff --git a/lisp/jit-lock.el b/lisp/jit-lock.el
> index a905936b6b9..14d09c979b9 100644
> --- a/lisp/jit-lock.el
> +++ b/lisp/jit-lock.el
> @@ -390,7 +390,7 @@ jit-lock--run-functions
>       'jit-lock-functions
>       (lambda (fun)
>         (pcase-let*
> -           ((res (funcall fun beg end))
> +           ((res (funcall fun (or tight-beg beg) (tight-end end)))
>              (`(,this-beg . ,this-end)
>               (if (eq (car-safe res) 'jit-lock-bounds)
>                   (cdr res) (cons beg end))))

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Stefan Monnier]

>> > However, this mechanism is rendered ineffective if a second function
>> > is add-hook'd onto jit-lock-functions.  Maybe this could be fixed,
>> > though it looks difficult.
>> I think we can "easily" handle this specific case if the
>> `bug-reference-prog-mode` function is added to the end of the hook
>> rather than to its beginning and use a patch along the lines of the
>> one below.
> Yes.  How about an optional parameter to jit-lock-register meaning "put
> this function at the beginning of jit-lock-functions", with the default
> meaning put the function at the end?

Sure.  Basically, the idea is that the function which is most likely to
grow the bounds (or to grow them most) should come first.

> I haven't tried it, but I don't think the patch below is quite enough.

I'd be surprised if it is, indeed, I just thought it was a better
description of the intention than whatever I could come up in words.


        Stefan

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Alan Mackenzie]

Hello, Stefan.

On Thu, Sep 02, 2021 at 14:46:51 -0400, Stefan Monnier wrote:
> >> > However, this mechanism is rendered ineffective if a second function
> >> > is add-hook'd onto jit-lock-functions.  Maybe this could be fixed,
> >> > though it looks difficult.
> >> I think we can "easily" handle this specific case if the
> >> `bug-reference-prog-mode` function is added to the end of the hook
> >> rather than to its beginning and use a patch along the lines of the
> >> one below.
> > Yes.  How about an optional parameter to jit-lock-register meaning "put
> > this function at the beginning of jit-lock-functions", with the default
> > meaning put the function at the end?

> Sure.  Basically, the idea is that the function which is most likely to
> grow the bounds (or to grow them most) should come first.

OK, thanks.

> > I haven't tried it, but I don't think the patch below is quite enough.

> I'd be surprised if it is, indeed, I just thought it was a better
> description of the intention than whatever I could come up in words.

Sorry, I didn't pick that up.  But I think I've worked out how to do it.

In words (;-), only the first function on jit-lock-functions should be
able to expand the region which gets `fontified' text properties.  This
expanded region will then be supplied to the subsequent functions.

Given how little used the `jit-lock-bounds' mechanism is (there is one
function in Emacs, font-lock-default-fontify-region, which uses it, and
a web search revealed only a single other instance, in lsp-mode on
git-hub), this shouldn't cause problems.  In fact, I'm not sure the
lsp-mode use of it is even correct.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Alan Mackenzie]

Hello, Stefan.

On Thu, Sep 02, 2021 at 19:24:51 +0000, Alan Mackenzie wrote:

[ .... ]

> In words (;-), only the first function on jit-lock-functions should be
> able to expand the region which gets `fontified' text properties.  This
> expanded region will then be supplied to the subsequent functions.

> Given how little used the `jit-lock-bounds' mechanism is (there is one
> function in Emacs, font-lock-default-fontify-region, which uses it, and
> a web search revealed only a single other instance, in lsp-mode on
> git-hub), this shouldn't cause problems.  In fact, I'm not sure the
> lsp-mode use of it is even correct.

OK, here's some code.  There's actually two versions of
jit-lock--run-functions here.  The second is a bit longer, but avoids
all the contrivances of using pcase-let*, and may be easier to read and
change.  They both fontify xdisp.c without the 7% penalty for the second
jit-lock-functions function, and are equally fast.



diff --git a/lisp/jit-lock.el b/lisp/jit-lock.el
index a1287926eb..bc45eb4e73 100644
--- a/lisp/jit-lock.el
+++ b/lisp/jit-lock.el
@@ -377,6 +377,7 @@ jit-lock-function
 			   (min (point-max) (+ start jit-lock-chunk-size)))
 			  'fontified 'defer)))))
 
+;;;; NEW STOUGH, 2021-09-02
 (defun jit-lock--run-functions (beg end)
   (let ((tight-beg nil) (tight-end nil)
         (loose-beg beg) (loose-end end))
@@ -384,23 +385,54 @@ jit-lock--run-functions
      'jit-lock-functions
      (lambda (fun)
        (pcase-let*
-           ((res (funcall fun beg end))
+           ;; The first function in `jit-lock-functions' can expand
+           ;; the region in `tight-beg' and `tight-end'.  This
+           ;; expanded region is passed to the subsequent functions.
+           ;; The union of all the regions the functions mark for
+           ;; fontification is stored in `loose-beg' and `loose-end'.
+           ((res (funcall fun (or tight-beg beg) (or tight-end end)))
             (`(,this-beg . ,this-end)
              (if (eq (car-safe res) 'jit-lock-bounds)
                  (cdr res) (cons beg end))))
-         ;; If all functions don't fontify the same region, we currently
-         ;; just try to "still be correct".  But we could go further and for
-         ;; the chunks of text that was fontified by some functions but not
-         ;; all, we could add text-properties indicating which functions were
-         ;; already run to avoid running them redundantly when we get to
-         ;; those chunks.
-         (setq tight-beg (max (or tight-beg (point-min)) this-beg))
-         (setq tight-end (min (or tight-end (point-max)) this-end))
+         (setq tight-beg (or tight-beg (min this-beg beg)))
+         (setq tight-end (or tight-end (max this-end end)))
          (setq loose-beg (min loose-beg this-beg))
          (setq loose-end (max loose-end this-end))
          nil)))
     `(,(min tight-beg beg) ,(max tight-end end) ,loose-beg ,loose-end)))
 
+;;;; NEWER STOUGH, 2021-09-02
+(defun jit-lock--run-functions (beg end)
+  (let ((loose-beg beg) (loose-end end)
+        tight-beg tight-end res)
+    (run-hook-wrapped
+     'jit-lock-functions
+     (lambda (fun)
+       (if (null tight-beg)
+           ;; The first function in `jit-lock-functions' can expand
+           ;; the fontified region, storing this in `tight-beg' and
+           ;; `tight-end'.
+           (progn
+             (setq res (funcall fun beg end))
+             (if (eq (car-safe res) 'jit-lock-bounds)
+                 (setq tight-beg (cadr res)
+                       tight-end (cddr res))
+               (setq tight-beg beg
+                     tight-end end)))
+         ;; The subsequent functions in `jit-lock-functions' take the
+         ;; possibly expanded region as arguments.
+         (setq res (funcall fun tight-beg tight-end)))
+
+       ;; The union of all the regions the functions mark for
+       ;; fontification is stored in `loose-beg' and `loose-end'.
+       (if (eq (car-safe res) 'jit-lock-bounds)
+           (setq loose-beg (min loose-beg (cadr res))
+                 loose-end (max loose-end (cddr res))))
+       nil))              ; prevent termination of `run-hook-wrapped'.
+
+    (list (or tight-beg beg) (or tight-end end) loose-beg loose-end)))
+;;;; END OF NEWER STOUGH
+
 (defun jit-lock-fontify-now (&optional start end)
   "Fontify current buffer from START to END.
 Defaults to the whole buffer.  END can be out of bounds."


-- 
Alan Mackenzie (Nuremberg, Germany).

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Eli Zaretskii]

> Date: Thu, 2 Sep 2021 19:24:51 +0000
> From: Alan Mackenzie <acm@muc.de>
> Cc: emacs-devel@gnu.org
> 
> In words (;-), only the first function on jit-lock-functions should be
> able to expand the region which gets `fontified' text properties.  This
> expanded region will then be supplied to the subsequent functions.
> 
> Given how little used the `jit-lock-bounds' mechanism is (there is one
> function in Emacs, font-lock-default-fontify-region, which uses it, and
> a web search revealed only a single other instance, in lsp-mode on
> git-hub), this shouldn't cause problems.  In fact, I'm not sure the
> lsp-mode use of it is even correct.

Bother: this is not future-proof, and certainly isn't scalable.  If we
are changing the protocol, can we instead come up with a more scalable
change, so that functions won't "fight" in the future who gets to be
"the first"?

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Eli Zaretskii]

> Date: Thu, 2 Sep 2021 21:08:18 +0000
> From: Alan Mackenzie <acm@muc.de>
> Cc: emacs-devel@gnu.org
> 
> Hello, Stefan.

I'm not him.

> +           ;; The first function in `jit-lock-functions' can expand
> +           ;; the region in `tight-beg' and `tight-end'.  This
> +           ;; expanded region is passed to the subsequent functions.
> +           ;; The union of all the regions the functions mark for
> +           ;; fontification is stored in `loose-beg' and `loose-end'.

The "union" part is not clear enough, and should IMO be explained.

More importantly, this cannot hide in a comment, it must be clearly
documented, both in doc strings and in the ELisp manual.  (Assuming
this is the change we will go with, of course.)

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Alan Mackenzie]

Hello, Eli.

On Fri, Sep 03, 2021 at 09:10:24 +0300, Eli Zaretskii wrote:
> > Date: Thu, 2 Sep 2021 19:24:51 +0000
> > From: Alan Mackenzie <acm@muc.de>
> > Cc: emacs-devel@gnu.org

> > In words (;-), only the first function on jit-lock-functions should be
> > able to expand the region which gets `fontified' text properties.  This
> > expanded region will then be supplied to the subsequent functions.

> > Given how little used the `jit-lock-bounds' mechanism is (there is one
> > function in Emacs, font-lock-default-fontify-region, which uses it, and
> > a web search revealed only a single other instance, in lsp-mode on
> > git-hub), this shouldn't cause problems.  In fact, I'm not sure the
> > lsp-mode use of it is even correct.

> Bother: this is not future-proof, and certainly isn't scalable.  If we
> are changing the protocol, can we instead come up with a more scalable
> change, so that functions won't "fight" in the future who gets to be
> "the first"?

I think we need to be clear about the current situation versus my
proposal.  If there is only one element (typically
font-lock-fontify-region) on jit-lock-functions, nothing changes.  With
several elements:

Current situation: The region marked with 'fontified text properties is
the _smallest_ returned by the jit-lock-functions functions.  If such a
function returns nil (which is usual), that region becomes precisely
(BEG END), and we lose all the benefit of jit-lock-bounds.

Proposed mechanism: The region marked with 'fontified is that supplied
by the first j-l-f function, typically font-lock-fontify-region.  This
is an enhancement.

Note that it is difficult to use the jit-lock-bounds returned by a
subsequent function, if they exceed the bounds returned by the first
function.  To do this safely, we would have to re-run all the previous
jit-lock-functions on the newly enlarged region.  This would be clumsy,
and wouldn't fit in well with our current scheme.

As for "fighting" to be the first function in j-l-f, I don't think that
should be a problem.  We can document the new &optional parameter to
jit-lock-register (not yet implemented) to say "don't use this unless
you really know what you're doing".

What we have isn't scalable in the sense you mean, and I don't think it
can be made scalable without massive changes in the jit-lock mechanism,
which might well reverse the benefits of using jit-lock-bounds (the 7%
saving in font locking time in CC Mode (and surely other modes, too)).

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Eli Zaretskii]

> Date: Fri, 3 Sep 2021 10:47:41 +0000
> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > Bother: this is not future-proof, and certainly isn't scalable.  If we
> > are changing the protocol, can we instead come up with a more scalable
> > change, so that functions won't "fight" in the future who gets to be
> > "the first"?
> 
> I think we need to be clear about the current situation versus my
> proposal.  If there is only one element (typically
> font-lock-fontify-region) on jit-lock-functions, nothing changes.  With
> several elements:
> 
> Current situation: The region marked with 'fontified text properties is
> the _smallest_ returned by the jit-lock-functions functions.  If such a
> function returns nil (which is usual), that region becomes precisely
> (BEG END), and we lose all the benefit of jit-lock-bounds.
> 
> Proposed mechanism: The region marked with 'fontified is that supplied
> by the first j-l-f function, typically font-lock-fontify-region.  This
> is an enhancement.
> 
> Note that it is difficult to use the jit-lock-bounds returned by a
> subsequent function, if they exceed the bounds returned by the first
> function.  To do this safely, we would have to re-run all the previous
> jit-lock-functions on the newly enlarged region.  This would be clumsy,
> and wouldn't fit in well with our current scheme.
> 
> As for "fighting" to be the first function in j-l-f, I don't think that
> should be a problem.  We can document the new &optional parameter to
> jit-lock-register (not yet implemented) to say "don't use this unless
> you really know what you're doing".
> 
> What we have isn't scalable in the sense you mean, and I don't think it
> can be made scalable without massive changes in the jit-lock mechanism,
> which might well reverse the benefits of using jit-lock-bounds (the 7%
> saving in font locking time in CC Mode (and surely other modes, too)).

You basically say that you consider what I said not important enough
to handle.  The only "arguments" you bring up are that you disagree
with my assessment.  I don't think those are useful arguments, because
who said your vision of the future is more accurate than mine?  But I
don't intend to continue arguing.

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Stefan Monnier]

> Bother: this is not future-proof, and certainly isn't scalable.  If we
> are changing the protocol, can we instead come up with a more scalable
> change, so that functions won't "fight" in the future who gets to be
> "the first"?

The change I proposed (I haven't had time to look at Alan's patch yet,
but IIUC it does what I proposed) does not change the protocol at all.
It just makes jit-lock use the information available in a slightly more
efficient way.

And while the number of packages using jit-lock tends to grow over time,
it's a *very* slow growth, so I think scaling is not
a significant concern.


        Stefan

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Stefan Monnier]

> Note that it is difficult to use the jit-lock-bounds returned by a
> subsequent function, if they exceed the bounds returned by the first
> function.  To do this safely, we would have to re-run all the previous
> jit-lock-functions on the newly enlarged region.  This would be clumsy,
> and wouldn't fit in well with our current scheme.

That's not the only option, tho.  We could also do the following:

- mark with `fontified` the intersection of all the
  `jit-lock-bounds` received (like we do now).

- mark the rest of those bounds with a new property which keeps track of
  those fontification functions that did not operate on them, so next
  time we need to jit-lock those pieces we only run the corresponding
  subset of functions.

I'm not claiming it would work better, tho: it would be more lazy
(more "jit") but it would also imply extra complexity when jitting
because we'd need to look for this new property and obey it.

> As for "fighting" to be the first function in j-l-f, I don't think that
> should be a problem.  We can document the new &optional parameter to
> jit-lock-register (not yet implemented) to say "don't use this unless
> you really know what you're doing".

Indeed.


        Stefan

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Stefan Monnier]

> More importantly, this cannot hide in a comment, it must be clearly
> documented, both in doc strings and in the ELisp manual.  (Assuming
> this is the change we will go with, of course.)

I don't understand why you think so.  It's a detail that should be
purely internal to jit-lock.el (and which should have no impact other
than in terms of performance).

E.g. it shouldn't affect those people writing packages which rely on
jit-lock (it doesn't change the rules of what to return in
`jit-lock-bounds`, for instance).


        Stefan

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Alan Mackenzie <acm@muc.de>,  emacs-devel@gnu.org
> Date: Fri, 03 Sep 2021 08:19:48 -0400
> 
> > Bother: this is not future-proof, and certainly isn't scalable.  If we
> > are changing the protocol, can we instead come up with a more scalable
> > change, so that functions won't "fight" in the future who gets to be
> > "the first"?
> 
> The change I proposed (I haven't had time to look at Alan's patch yet,
> but IIUC it does what I proposed) does not change the protocol at all.
> It just makes jit-lock use the information available in a slightly more
> efficient way.

Which change is that, and how does it handle the issue at hand?

> And while the number of packages using jit-lock tends to grow over time,
> it's a *very* slow growth, so I think scaling is not
> a significant concern.

Famous last words.

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Alan Mackenzie <acm@muc.de>,  emacs-devel@gnu.org
> Date: Fri, 03 Sep 2021 08:30:28 -0400
> 
> > More importantly, this cannot hide in a comment, it must be clearly
> > documented, both in doc strings and in the ELisp manual.  (Assuming
> > this is the change we will go with, of course.)
> 
> I don't understand why you think so.  It's a detail that should be
> purely internal to jit-lock.el (and which should have no impact other
> than in terms of performance).
> 
> E.g. it shouldn't affect those people writing packages which rely on
> jit-lock (it doesn't change the rules of what to return in
> `jit-lock-bounds`, for instance).

But it does change the result.  Users of jit-lock-bounds should
definitely know the importance of being "the first function".

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Alan Mackenzie]

Hello, Eli.

On Fri, Sep 03, 2021 at 14:24:31 +0300, Eli Zaretskii wrote:
> > Date: Fri, 3 Sep 2021 10:47:41 +0000
> > Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > Bother: this is not future-proof, and certainly isn't scalable.  If we
> > > are changing the protocol, can we instead come up with a more scalable
> > > change, so that functions won't "fight" in the future who gets to be
> > > "the first"?

> > I think we need to be clear about the current situation versus my
> > proposal.  If there is only one element (typically
> > font-lock-fontify-region) on jit-lock-functions, nothing changes.  With
> > several elements:

> > Current situation: The region marked with 'fontified text properties is
> > the _smallest_ returned by the jit-lock-functions functions.  If such a
> > function returns nil (which is usual), that region becomes precisely
> > (BEG END), and we lose all the benefit of jit-lock-bounds.

> > Proposed mechanism: The region marked with 'fontified is that supplied
> > by the first j-l-f function, typically font-lock-fontify-region.  This
> > is an enhancement.

> > Note that it is difficult to use the jit-lock-bounds returned by a
> > subsequent function, if they exceed the bounds returned by the first
> > function.  To do this safely, we would have to re-run all the previous
> > jit-lock-functions on the newly enlarged region.  This would be clumsy,
> > and wouldn't fit in well with our current scheme.

> > As for "fighting" to be the first function in j-l-f, I don't think that
> > should be a problem.  We can document the new &optional parameter to
> > jit-lock-register (not yet implemented) to say "don't use this unless
> > you really know what you're doing".

> > What we have isn't scalable in the sense you mean, and I don't think it
> > can be made scalable without massive changes in the jit-lock mechanism,
> > which might well reverse the benefits of using jit-lock-bounds (the 7%
> > saving in font locking time in CC Mode (and surely other modes, too)).

> You basically say that you consider what I said not important enough
> to handle.

That's not at all what I meant to say.  I'm sorry that it came out like
that.

> The only "arguments" you bring up are that you disagree with my
> assessment.

No.  The matter we're discussing is somewhat complicated, and I think
we're seeing different aspects of it.  That's why I wrote out in detail
what I am seeing.  I don't yet see what you're seeing.

> I don't think those are useful arguments, because who said your vision
> of the future is more accurate than mine?  ....

Not me.  But I think winning back that 7% of fontification speed is worth
the effort.  I think we're still at the stage of exploring alternatives.
Stefan has suggested one or two.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Alan Mackenzie]

Hello, Eli.

On Fri, Sep 03, 2021 at 09:10:24 +0300, Eli Zaretskii wrote:
> > Date: Thu, 2 Sep 2021 19:24:51 +0000
> > From: Alan Mackenzie <acm@muc.de>
> > Cc: emacs-devel@gnu.org

> > In words (;-), only the first function on jit-lock-functions should
> > be able to expand the region which gets `fontified' text properties.
> > This expanded region will then be supplied to the subsequent
> > functions.

> > Given how little used the `jit-lock-bounds' mechanism is (there is
> > one function in Emacs, font-lock-default-fontify-region, which uses
> > it, and a web search revealed only a single other instance, in
> > lsp-mode on git-hub), this shouldn't cause problems.  In fact, I'm
> > not sure the lsp-mode use of it is even correct.

> Bother: this is not future-proof, and certainly isn't scalable.  If we
> are changing the protocol, can we instead come up with a more scalable
> change, so that functions won't "fight" in the future who gets to be
> "the first"?

OK, so the problem is how do we cope with two (or even several) "first"
functions?

How about something like this:
o - We still have a first function, font-lock-fontify-region.
o - We call the next function with the jit-lock-bounds returned by the
  previous one.  Repeat this step with steadily expanding bounds for
  each function in jit-lock-functions.
o - if (< BEG-final BEG-1) we go through jit-lock-functions again on the
  region (BEG-final BEG-1).  Do the same for END-final.  During this
  stage, we ignore the returned jit-lock-bounds.
o - We set the `fontified' text properties on the region (BEG-final
  END-final).

This needn't actually be too complicated.  The current
jit-lock--run-functions already calculates BEG-final and END-final (it
calls them loose-beg and loose-end).

For this mechanism, it would still be best to have all the functions
using jit-lock-bounds together at the start of jit-lock-functions,
though this would be an optimsation rather than essential to the
functionality.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Alan Mackenzie]

Hello, Eli and Stefan.

On Fri, Sep 03, 2021 at 16:52:55 +0000, Alan Mackenzie wrote:
> On Fri, Sep 03, 2021 at 09:10:24 +0300, Eli Zaretskii wrote:
> > > Date: Thu, 2 Sep 2021 19:24:51 +0000
> > > From: Alan Mackenzie <acm@muc.de>
> > > Cc: emacs-devel@gnu.org

> > > In words (;-), only the first function on jit-lock-functions should
> > > be able to expand the region which gets `fontified' text properties.
> > > This expanded region will then be supplied to the subsequent
> > > functions.

> > > Given how little used the `jit-lock-bounds' mechanism is (there is
> > > one function in Emacs, font-lock-default-fontify-region, which uses
> > > it, and a web search revealed only a single other instance, in
> > > lsp-mode on git-hub), this shouldn't cause problems.  In fact, I'm
> > > not sure the lsp-mode use of it is even correct.

> > Bother: this is not future-proof, and certainly isn't scalable.  If we
> > are changing the protocol, can we instead come up with a more scalable
> > change, so that functions won't "fight" in the future who gets to be
> > "the first"?

> OK, so the problem is how do we cope with two (or even several) "first"
> functions?

> How about something like this:
> o - We still have a first function, font-lock-fontify-region.
> o - We call the next function with the jit-lock-bounds returned by the
>   previous one.  Repeat this step with steadily expanding bounds for
>   each function in jit-lock-functions.
> o - if (< BEG-final BEG-1) we go through jit-lock-functions again on the
>   region (BEG-final BEG-1).  Do the same for END-final.  During this
>   stage, we ignore the returned jit-lock-bounds.
> o - We set the `fontified' text properties on the region (BEG-final
>   END-final).

> This needn't actually be too complicated.  The current
> jit-lock--run-functions already calculates BEG-final and END-final (it
> calls them loose-beg and loose-end).

> For this mechanism, it would still be best to have all the functions
> using jit-lock-bounds together at the start of jit-lock-functions,
> though this would be an optimsation rather than essential to the
> functionality.

OK, I've hacked up a trial implementation, though I haven't started
testing it yet.  The key is to extract jit-lock--fontify-now-1 from
jit-lock-fontify-now, and have it call itself recursively to handle the
expansion of the region caused by a jit-lock-bounds returned by the
second or later function.

This should be easy to test and verify as correct, yet the recursion
should be invoked rarely enough that it won't lead to inefficiencies.

This implementation should resolve Eli's concerns about handling two
or more "first" functions in jit-lock-functions.



(defun jit-lock--run-functions (beg end)
  (let ((tight-beg nil) (tight-end nil) ; The region we have fully fontified.
        (loose-beg beg) (loose-end end)) ; The maximum region we have fontified
                                         ; with at least some of
                                         ; `jit-lock-functions'.
    (run-hook-wrapped
     'jit-lock-functions
     (lambda (fun)
       (pcase-let*
           ;; The first function in `jit-lock-functions' can expand
           ;; the region into `tight-beg' and `tight-end'.  These
           ;; arguments are passed to the next function (if any).
           ;; Subsequently, the expanded region from any function is
           ;; stored in `loose-beg' and `loose-end', and is likewise
           ;; passed to the next function.
           ((res (funcall fun loose-beg loose-end))
            (`(,this-beg . ,this-end)
             (if (eq (car-safe res) 'jit-lock-bounds)
                 (cdr res) (cons beg end))))
         (or tight-beg (setq tight-beg (min this-beg beg)))
         (or tight-end (setq tight-end (max this-end end)))
         (setq loose-beg (min loose-beg this-beg))
         (setq loose-end (max loose-end this-end))
         nil)))
    `(,(or tight-beg beg) ,(or tight-end end) ,loose-beg ,loose-end)))

(defun jit-lock--fontify-now-1 (start end)
  "Fontify current buffer from START to END, possibly more.
Return the list (RES-START RES-END), the entire region which was fontified."
  (let ((res-start start) (res-end end) next)
    ;; Fontify chunks beginning at START.  The end of a chunk is
    ;; either `end', or the start of a region before `end' that has
    ;; already been fontified.
    (while (and start (< start end))
      ;; Determine the end of this chunk.
      (setq next (or (text-property-any start end 'fontified t)
                     end))

      ;; Avoid unnecessary work if the chunk is empty (bug#23278).
     (when (> next start)
        ;; Fontify the chunk, and mark it as fontified.  We mark it
        ;; first, to make sure that we don't indefinitely re-execute
        ;; this fontification if an error occurs.
        (put-text-property start next 'fontified t)
        (pcase-let
            ;; `tight' is the part we've fully refontified, and
            ;; `loose' is the part we've partly refontified (some of
            ;; the functions have refontified it but maybe not all).
            ((`(,tight-beg ,tight-end ,loose-beg ,loose-end)
              (condition-case err
                  (jit-lock--run-functions start next)
                ;; If the user quits (which shouldn't happen in normal
                ;; on-the-fly jit-locking), make sure the fontification
                ;; will be performed before displaying the block again.
                (quit (put-text-property start next 'fontified nil)
                      (signal (car err) (cdr err))))))

          ;; In case we fontified more than requested, take advantage
          ;; of the good news.
          (when (or (< tight-beg start) (> tight-end next))
            (put-text-property tight-beg tight-end 'fontified t))

          ;; If we've partially fontified (i.e. only run some
          ;; `jit-lock-functions' on parts of the buffer beyond (START
          ;; END), refontify those parts entirely.
          (when (< loose-beg tight-beg)
            (pcase-let
                ((`(,sub-beg ,_)
                  (jit-lock--fontify-now-1 loose-beg tight-beg)))
              (setq tight-beg sub-beg)))
          (when (> loose-end tight-end)
            (pcase-let
                ((`(,_ ,sub-end)
                  (jit-lock--fontify-now-1 tight-end loose-end)))
              (setq tight-end sub-end)))

          (setq res-start (min res-start tight-beg)
                res-end (max res-end tight-end))))

      ;; Skip to the end of the fully refontified part.
      (setq start res-end)
      ;; Find the start of the next chunk, if any.
      (setq start (text-property-any start end 'fontified nil)))

    (list res-start res-end)))

(defun jit-lock-fontify-now (&optional start end)
  "Fontify current buffer from START to END.
Defaults to the whole buffer.  END can be out of bounds."
  (with-buffer-prepared-for-jit-lock
   (save-excursion
     (unless start (setq start (point-min)))
     (setq end (if end (min end (point-max)) (point-max)))
     (save-match-data
       (let ((orig-start start))
         (pcase-let
             ;; `tight' is the part we've fully refontified.
             ((`(,tight-beg ,tight-end)
               (jit-lock--fontify-now-1 start end)))

           ;; Make sure the contextual refontification doesn't re-refontify
           ;; what's already been refontified.
           (when (and jit-lock-context-unfontify-pos
                      (< jit-lock-context-unfontify-pos tight-end)
                      (>= jit-lock-context-unfontify-pos tight-beg)
                      ;; Don't move boundary forward if we have to
                      ;; refontify previous text.  Otherwise, we risk moving
                      ;; it past the end of the multiline property and thus
                      ;; forget about this multiline region altogether.
                      (not (get-text-property tight-beg
                                              'jit-lock-defer-multiline)))
             (setq jit-lock-context-unfontify-pos tight-end))

           ;; The redisplay engine has already rendered the buffer up-to
           ;; `orig-start' and won't notice if the above jit-lock-functions
           ;; changed the appearance of any part of the buffer prior
           ;; to that.  So if `tight-beg' is before `orig-start', we need to
           ;; cause a new redisplay cycle after this one so that the changes
           ;; are properly reflected on screen.
           ;; To make such repeated redisplay happen less often, we can
           ;; eagerly extend the refontified region with
           ;; jit-lock-after-change-extend-region-functions.
           (when (< tight-beg orig-start)
             (run-with-timer 0 nil #'jit-lock-force-redisplay
                             (copy-marker tight-beg)
                             (copy-marker orig-start)))))))))


-- 
Alan Mackenzie (Nuremberg, Germany).

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Stefan Monnier]

> But it does change the result.

It changes the overall behavior a bit, yes.  And of course, that might
trigger bugs somewhere, like any other change.  But other than that, it
should not change the actual final result other than how fast we get to
it, no.

> Users of `jit-lock-bounds` should definitely know the importance of
> being "the first function".

Actually, we could refine the patch to make the ordering automatic,
based on measurements so the users of `jit-lock-register` don't need to
know about it.


        Stefan

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Eli Zaretskii]

> Date: Fri, 3 Sep 2021 20:51:22 +0000
> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> OK, I've hacked up a trial implementation, though I haven't started
> testing it yet.  The key is to extract jit-lock--fontify-now-1 from
> jit-lock-fontify-now, and have it call itself recursively to handle the
> expansion of the region caused by a jit-lock-bounds returned by the
> second or later function.
> 
> This should be easy to test and verify as correct, yet the recursion
> should be invoked rarely enough that it won't lead to inefficiencies.
> 
> This implementation should resolve Eli's concerns about handling two
> or more "first" functions in jit-lock-functions.

Thanks.

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: acm@muc.de,  emacs-devel@gnu.org
> Date: Fri, 03 Sep 2021 18:25:36 -0400
> 
> > But it does change the result.
> 
> It changes the overall behavior a bit, yes.  And of course, that might
> trigger bugs somewhere, like any other change.  But other than that, it
> should not change the actual final result other than how fast we get to
> it, no.

I'm looking at this from the POV of someone who writes a function to
be registered with JIT font-lock.  They need to understand these
details to be able to write code which will do what they want.

> > Users of `jit-lock-bounds` should definitely know the importance of
> > being "the first function".
> 
> Actually, we could refine the patch to make the ordering automatic,
> based on measurements so the users of `jit-lock-register` don't need to
> know about it.

They would still know about the automatic ordering because if some
other function gets put at the first place, the results will be
different, and that needs to be explained.

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Stefan Monnier]

>> It changes the overall behavior a bit, yes.  And of course, that might
>> trigger bugs somewhere, like any other change.  But other than that, it
>> should not change the actual final result other than how fast we get to
>> it, no.
>
> I'm looking at this from the POV of someone who writes a function to
> be registered with JIT font-lock.  They need to understand these
> details to be able to write code which will do what they want.

Why should they?  The function is asked to handle region BEG...END and
it may elect to handle a larger region.  For efficiency reasons, most
such function will extend the BEG...END region as little as possible, so
they don't really have much choice in terms of which part of the buffer
to handle: as small as possible, yet larger or equal to BEG...END.

As for the value those functions return, it can always be nil unless
they elect to tell jit-lock about that larger region they decided to
handle in which case jit-lock will try and take advantage of that info
to avoid redundant work.

This description has been valid for a while and the changes discussed
here do not impact it at all.

> They would still know about the automatic ordering because if some
> other function gets put at the first place, the results will be
> different, and that needs to be explained.

I don't see in what sense "the results will be different".
Which results are you talking a bout?  What kind of difference do you foresee?


        Stefan

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: acm@muc.de,  emacs-devel@gnu.org
> Date: Sat, 04 Sep 2021 09:36:04 -0400
> 
> >> It changes the overall behavior a bit, yes.  And of course, that might
> >> trigger bugs somewhere, like any other change.  But other than that, it
> >> should not change the actual final result other than how fast we get to
> >> it, no.
> >
> > I'm looking at this from the POV of someone who writes a function to
> > be registered with JIT font-lock.  They need to understand these
> > details to be able to write code which will do what they want.
> 
> Why should they?

To achieve their goals, of course.

I really don't understand why we are having this conversation.  It's
almost as if you claimed that documenting non-trivial behavior is a
bad idea, or a luxury.  But you cannot be seriously thinking that.

> This description has been valid for a while and the changes discussed
> here do not impact it at all.

Excuse me, but the jit-lock-bounds was almost completely undocumented,
until I did that a few days ago.  So what description are you alluding
to which has been valid?

> > They would still know about the automatic ordering because if some
> > other function gets put at the first place, the results will be
> > different, and that needs to be explained.
> 
> I don't see in what sense "the results will be different".
> Which results are you talking a bout?

The results of running jit-lock-functions.  those which really perform
fontifications result in faces, others result in whatever they do.

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Stefan Monnier]

>> > I'm looking at this from the POV of someone who writes a function to
>> > be registered with JIT font-lock.  They need to understand these
>> > details to be able to write code which will do what they want.
>> Why should they?
> To achieve their goals, of course.

[ I'll call "client functions" those functions passed to
  `jit-lock-register`, like `font-lock-fontify-region`,
  `goto-address-fontify-region`, `bug-reference-fontify`, ...  ]

I still can't see in which way the specific details of how jit-lock
chooses the BEG...END arguments and uses the returned `jit-lock-bounds`
affects the authors of client functions.

> I really don't understand why we are having this conversation.  It's
> almost as if you claimed that documenting non-trivial behavior is a
> bad idea, or a luxury.  But you cannot be seriously thinking that.

I think it's a bad idea to document internal details, yes.
Those who need to know those details can look at the code.

But my understanding of what you're saying is that you don't consider
"how `jit-lock-bounds` are used" to be an internal detail.  Instead you
consider these to be part of the "protocol" that the writer of client
functions needs to know in order for those functions to work correctly.
And I can't understand why you'd think that.  I think even in the
current situation, none of what we have discussed has prompted a need or
desire to change client functions: they're oblivious to the change
being discussed.

The only part where it might be visible is in a new argument to
`jit-lock-register` that would specify whether a client function would
like to come first or not.

> Excuse me, but the jit-lock-bounds was almost completely undocumented,
> until I did that a few days ago.  So what description are you alluding
> to which has been valid?

The implicit one that comes from the range of ways those client
functions could be called in the past and how their return value could
be used.  The change makes almost no difference in this respect (it
might change the frequency of some cases, but most of the behaviors that
are possible in the new setup were also possible in the old setup).

>> I don't see in what sense "the results will be different".
>> Which results are you talking a bout?
> The results of running jit-lock-functions.  those which really perform
> fontifications result in faces, others result in whatever they do.

Yes, the code is different, so there are differences in the result of
some internal steps.  But those "results" are internal.  Why would
anyone care about them.  Who and how or when would notice them?
Do you claim that it can result in a different rendering on screen?
Or do you claim that it can result in the need to write client
functions differently?
If so, could you give some kind of scenario where that could happen?
If not, what else?


        Stefan

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Alan Mackenzie]

Hello, Eli.

On Sat, Sep 04, 2021 at 09:09:10 +0300, Eli Zaretskii wrote:
> > Date: Fri, 3 Sep 2021 20:51:22 +0000
> > Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > OK, I've hacked up a trial implementation, though I haven't started
> > testing it yet.  The key is to extract jit-lock--fontify-now-1 from
> > jit-lock-fontify-now, and have it call itself recursively to handle the
> > expansion of the region caused by a jit-lock-bounds returned by the
> > second or later function.

> > This should be easy to test and verify as correct, yet the recursion
> > should be invoked rarely enough that it won't lead to inefficiencies.

> > This implementation should resolve Eli's concerns about handling two
> > or more "first" functions in jit-lock-functions.

> Thanks.

OK, here's a working patch.  When I run my favourite benchmark,
time-scroll on xdisp.c, ....

(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)))

(defun time-scroll (&optional arg)
  (interactive "P")
  (message "%s"
           (time-it
            (condition-case nil
                (while t
                  (if arg (scroll-down) (scroll-up))
                  (sit-for 0))
              (error nil)))))

..... it takes 21.2s.

This is with jit-lock-functions set to 

    (font-lock-fontify-region bug-reference-fontify t)

..  However, with the order of these functions reversed:

    (bug-reference-fontify font-lock-fontify-region t)

, it takes 27.9s.  So it would seem the cost of having a jit-lock
function returning a jit-lock-bounds structure when it's not the first
function is high.  That's using the strategy of a full refontification of
the "extra" regions of the buffer returned in that structure.  Maybe that
strategy is not optimal.

Here's the current version of the patch:



diff --git a/lisp/jit-lock.el b/lisp/jit-lock.el
index a1287926eb..0c71201e6b 100644
--- a/lisp/jit-lock.el
+++ b/lisp/jit-lock.el
@@ -378,28 +378,90 @@ jit-lock-function
 			  'fontified 'defer)))))
 
 (defun jit-lock--run-functions (beg end)
-  (let ((tight-beg nil) (tight-end nil)
-        (loose-beg beg) (loose-end end))
+  (let ((tight-beg nil) (tight-end nil) ; The region we have fully fontified.
+        (loose-beg beg) (loose-end end)) ; The maximum region we have fontified
+                                         ; with at least some of
+                                         ; `jit-lock-functions'.
     (run-hook-wrapped
      'jit-lock-functions
      (lambda (fun)
        (pcase-let*
-           ((res (funcall fun beg end))
+           ;; The first function in `jit-lock-functions' can expand
+           ;; the region into `tight-beg' and `tight-end'.  These
+           ;; arguments are passed to the next function (if any).
+           ;; Subsequently, the expanded region from any function is
+           ;; stored in `loose-beg' and `loose-end', and is likewise
+           ;; passed to the next function.
+           ((res (funcall fun loose-beg loose-end))
             (`(,this-beg . ,this-end)
              (if (eq (car-safe res) 'jit-lock-bounds)
                  (cdr res) (cons beg end))))
-         ;; If all functions don't fontify the same region, we currently
-         ;; just try to "still be correct".  But we could go further and for
-         ;; the chunks of text that was fontified by some functions but not
-         ;; all, we could add text-properties indicating which functions were
-         ;; already run to avoid running them redundantly when we get to
-         ;; those chunks.
-         (setq tight-beg (max (or tight-beg (point-min)) this-beg))
-         (setq tight-end (min (or tight-end (point-max)) this-end))
+         (or tight-beg (setq tight-beg (min this-beg beg)))
+         (or tight-end (setq tight-end (max this-end end)))
          (setq loose-beg (min loose-beg this-beg))
          (setq loose-end (max loose-end this-end))
          nil)))
-    `(,(min tight-beg beg) ,(max tight-end end) ,loose-beg ,loose-end)))
+    `(,(or tight-beg beg) ,(or tight-end end) ,loose-beg ,loose-end)))
+
+(defun jit-lock--fontify-now-1 (start end)
+  "Fontify current buffer from START to END, possibly more.
+Return the list (RES-START RES-END), the entire region which was fontified."
+  (let ((res-start start) (res-end end) next)
+    ;; Fontify chunks beginning at START.  The end of a chunk is
+    ;; either `end', or the start of a region before `end' that has
+    ;; already been fontified.
+    (while (and start (< start end))
+      ;; Determine the end of this chunk.
+      (setq next (or (text-property-any start end 'fontified t)
+                     end))
+
+      ;; Avoid unnecessary work if the chunk is empty (bug#23278).
+      (when (> next start)
+        ;; Fontify the chunk, and mark it as fontified.  We mark it
+        ;; first, to make sure that we don't indefinitely re-execute
+        ;; this fontification if an error occurs.
+        (put-text-property start next 'fontified t)
+        (pcase-let
+            ;; `tight' is the part we've fully refontified, and
+            ;; `loose' is the part we've partly refontified (some of
+            ;; the functions have refontified it but maybe not all).
+            ((`(,tight-beg ,tight-end ,loose-beg ,loose-end)
+              (condition-case err
+                  (jit-lock--run-functions start next)
+                ;; If the user quits (which shouldn't happen in normal
+                ;; on-the-fly jit-locking), make sure the fontification
+                ;; will be performed before displaying the block again.
+                (quit (put-text-property start next 'fontified nil)
+                      (signal (car err) (cdr err))))))
+
+          ;; In case we fontified more than requested, take advantage
+          ;; of the good news.
+          (when (or (< tight-beg start) (> tight-end next))
+            (put-text-property tight-beg tight-end 'fontified t))
+
+          ;; If we've partially fontified (i.e. only run some
+          ;; `jit-lock-functions' on parts of the buffer beyond (START
+          ;; END), refontify those parts entirely.
+          (when (< loose-beg tight-beg)
+            (pcase-let
+                ((`(,sub-beg ,_)
+                  (jit-lock--fontify-now-1 loose-beg tight-beg)))
+              (setq tight-beg sub-beg)))
+          (when (> loose-end tight-end)
+            (pcase-let
+                ((`(,_ ,sub-end)
+                  (jit-lock--fontify-now-1 tight-end loose-end)))
+              (setq tight-end sub-end)))
+
+          (setq res-start (min res-start tight-beg)
+                res-end (max res-end tight-end))))
+
+      ;; Skip to the end of the fully refontified part.
+      (setq start next)
+      ;; Find the start of the next chunk, if any.
+      (setq start (text-property-any start end 'fontified nil)))
+
+    (list res-start res-end)))
 
 (defun jit-lock-fontify-now (&optional start end)
   "Fontify current buffer from START to END.
@@ -408,72 +470,39 @@ jit-lock-fontify-now
    (save-excursion
      (unless start (setq start (point-min)))
      (setq end (if end (min end (point-max)) (point-max)))
-     (let ((orig-start start) next)
-       (save-match-data
-	 ;; Fontify chunks beginning at START.  The end of a
-	 ;; chunk is either `end', or the start of a region
-	 ;; before `end' that has already been fontified.
-	 (while (and start (< start end))
-	   ;; Determine the end of this chunk.
-	   (setq next (or (text-property-any start end 'fontified t)
-			  end))
-
-           ;; Avoid unnecessary work if the chunk is empty (bug#23278).
-           (when (> next start)
-             ;; Fontify the chunk, and mark it as fontified.
-             ;; We mark it first, to make sure that we don't indefinitely
-             ;; re-execute this fontification if an error occurs.
-             (put-text-property start next 'fontified t)
-             (pcase-let
-                 ;; `tight' is the part we've fully refontified, and `loose'
-                 ;; is the part we've partly refontified (some of the
-                 ;; functions have refontified it but maybe not all).
-                 ((`(,tight-beg ,tight-end ,loose-beg ,_loose-end)
-                   (condition-case err
-                       (jit-lock--run-functions start next)
-                     ;; If the user quits (which shouldn't happen in normal
-                     ;; on-the-fly jit-locking), make sure the fontification
-                     ;; will be performed before displaying the block again.
-                     (quit (put-text-property start next 'fontified nil)
-                           (signal (car err) (cdr err))))))
-
-               ;; In case we fontified more than requested, take
-               ;; advantage of the good news.
-               (when (or (< tight-beg start) (> tight-end next))
-                 (put-text-property tight-beg tight-end 'fontified t))
-
-               ;; Make sure the contextual refontification doesn't re-refontify
-               ;; what's already been refontified.
-               (when (and jit-lock-context-unfontify-pos
-                          (< jit-lock-context-unfontify-pos tight-end)
-                          (>= jit-lock-context-unfontify-pos tight-beg)
-                          ;; Don't move boundary forward if we have to
-                          ;; refontify previous text.  Otherwise, we risk moving
-                          ;; it past the end of the multiline property and thus
-                          ;; forget about this multiline region altogether.
-                          (not (get-text-property tight-beg
-                                                  'jit-lock-defer-multiline)))
-                 (setq jit-lock-context-unfontify-pos tight-end))
-
-               ;; The redisplay engine has already rendered the buffer up-to
-               ;; `orig-start' and won't notice if the above jit-lock-functions
-               ;; changed the appearance of any part of the buffer prior
-               ;; to that.  So if `loose-beg' is before `orig-start', we need to
-               ;; cause a new redisplay cycle after this one so that the changes
-               ;; are properly reflected on screen.
-               ;; To make such repeated redisplay happen less often, we can
-               ;; eagerly extend the refontified region with
-               ;; jit-lock-after-change-extend-region-functions.
-               (when (< loose-beg orig-start)
-                 (run-with-timer 0 nil #'jit-lock-force-redisplay
-                                 (copy-marker loose-beg)
-                                 (copy-marker orig-start)))
-
-               ;; Skip to the end of the fully refontified part.
-               (setq start tight-end)))
-           ;; Find the start of the next chunk, if any.
-           (setq start
-                 (text-property-any start end 'fontified nil))))))))
+     (save-match-data
+       (let ((orig-start start))
+         (pcase-let
+             ;; `tight' is the part we've fully refontified.
+             ((`(,tight-beg ,tight-end)
+               (jit-lock--fontify-now-1 start end)))
+
+           ;; Make sure the contextual refontification doesn't re-refontify
+           ;; what's already been refontified.
+           (when (and jit-lock-context-unfontify-pos
+                      (< jit-lock-context-unfontify-pos tight-end)
+                      (>= jit-lock-context-unfontify-pos tight-beg)
+                      ;; Don't move boundary forward if we have to
+                      ;; refontify previous text.  Otherwise, we risk moving
+                      ;; it past the end of the multiline property and thus
+                      ;; forget about this multiline region altogether.
+                      (not (get-text-property tight-beg
+                                              'jit-lock-defer-multiline)))
+             (setq jit-lock-context-unfontify-pos tight-end))
+
+           ;; The redisplay engine has already rendered the buffer up-to
+           ;; `orig-start' and won't notice if the above jit-lock-functions
+           ;; changed the appearance of any part of the buffer prior
+           ;; to that.  So if `tight-beg' is before `orig-start', we need to
+           ;; cause a new redisplay cycle after this one so that the changes
+           ;; are properly reflected on screen.
+           ;; To make such repeated redisplay happen less often, we can
+           ;; eagerly extend the refontified region with
+           ;; jit-lock-after-change-extend-region-functions.
+           (when (< tight-beg orig-start)
+             (run-with-timer 0 nil #'jit-lock-force-redisplay
+                             (copy-marker tight-beg)
+                             (copy-marker orig-start)))))))))
 
 (defun jit-lock-force-redisplay (start end)
   "Force the display engine to re-render START's buffer from START to END.


-- 
Alan Mackenzie (Nuremberg, Germany).

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: acm@muc.de,  emacs-devel@gnu.org
> Date: Sat, 04 Sep 2021 10:44:43 -0400
> 
> I still can't see in which way the specific details of how jit-lock
> chooses the BEG...END arguments and uses the returned `jit-lock-bounds`
> affects the authors of client functions.
> 
> > I really don't understand why we are having this conversation.  It's
> > almost as if you claimed that documenting non-trivial behavior is a
> > bad idea, or a luxury.  But you cannot be seriously thinking that.
> 
> I think it's a bad idea to document internal details, yes.
> Those who need to know those details can look at the code.
> 
> But my understanding of what you're saying is that you don't consider
> "how `jit-lock-bounds` are used" to be an internal detail.  Instead you
> consider these to be part of the "protocol" that the writer of client
> functions needs to know in order for those functions to work correctly.
> And I can't understand why you'd think that.  I think even in the
> current situation, none of what we have discussed has prompted a need or
> desire to change client functions: they're oblivious to the change
> being discussed.

We have the reason right before our eyes: what Alan needs to do.  If
these details are not important, why does he work on changing them?

> The only part where it might be visible is in a new argument to
> `jit-lock-register` that would specify whether a client function would
> like to come first or not.

That's one thing to be documented (if being the first is indeed
important).  And you cannot explain that without telling something
about how this stuff works.

> > Excuse me, but the jit-lock-bounds was almost completely undocumented,
> > until I did that a few days ago.  So what description are you alluding
> > to which has been valid?
> 
> The implicit one that comes from the range of ways those client
> functions could be called in the past and how their return value could
> be used.

According to Aristotle's logic, you can tell anything you want about a
non-existing thing, and no one will be able to prove you wrong.

> >> I don't see in what sense "the results will be different".
> >> Which results are you talking a bout?
> > The results of running jit-lock-functions.  those which really perform
> > fontifications result in faces, others result in whatever they do.
> 
> Yes, the code is different, so there are differences in the result of
> some internal steps.  But those "results" are internal.

They aren't internal, because faces are visible.

> Do you claim that it can result in a different rendering on screen?

That's one possibility, yes.  And for the functions that do something
other than fontifications, who knows what the results could be?

> If so, could you give some kind of scenario where that could happen?

Why do I need to come up with a scenario, when it's clear as a day
that programming blindly to an insufficiently documented interface is
asking for trouble?

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Stefan Monnier]

> , it takes 27.9s.  So it would seem the cost of having a jit-lock
> function returning a jit-lock-bounds structure when it's not the first
> function is high.  That's using the strategy of a full refontification of
> the "extra" regions of the buffer returned in that structure.

How does it compare to the performance with the old/current
jit-lock code?

> Maybe that strategy is not optimal.

I think it leads to many calls to the client functions with small
regions, which for font-lock at least is not optimal indeed.

Maybe to speed things up, another option is to grow the chunk size
a bit.


        Stefan

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Alan Mackenzie]

Hello, Stefan.

On Sat, Sep 04, 2021 at 11:00:53 -0400, Stefan Monnier wrote:
> > , it takes 27.9s.  So it would seem the cost of having a jit-lock
> > function returning a jit-lock-bounds structure when it's not the first
> > function is high.  That's using the strategy of a full refontification of
> > the "extra" regions of the buffer returned in that structure.

> How does it compare to the performance with the old/current
> jit-lock code?

That takes ~22.6s.

> > Maybe that strategy is not optimal.

> I think it leads to many calls to the client functions with small
> regions, which for font-lock at least is not optimal indeed.

> Maybe to speed things up, another option is to grow the chunk size
> a bit.

Maybe.  An advantage of a small chunk size is that fontifying a single
screen can be done with a maximum 499 bytes "inefficiency" off the end
of a screen.  If we were to increase jit-lock-chunk-size to, say 2000,
more of the next screen would be getting fontified, perhaps wastefully.
I don't know how important this is.  Maybe I should try it.

Indeed.  With jit-lock-chunk-size at 2000, time-scroll on xdisp.c takes:

(current code): 16.4s
(new proposed code): 16.1s

..  This speed up may well be particular to CC Mode.

Let's try jit-lock-chunk-size at 8000:

(current code): 15.1s
(new proposed code): 15.1s

..  So, yes, it would seem a larger chunk size is advantageous for CC
Mode.  In Emacs Lisp Mode, scrolling through jit-lock.el takes:

(500): 0.195s
(8000): 0.184s

..  So the advantage of a bigger chunk size is less marked, here.

Maybe we should consider increasing the default jit-lock-chunk-size.


>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Eli Zaretskii]

> Date: Sat, 4 Sep 2021 15:32:57 +0000
> From: Alan Mackenzie <acm@muc.de>
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> 
> > Maybe to speed things up, another option is to grow the chunk size
> > a bit.
> 
> Maybe.  An advantage of a small chunk size is that fontifying a single
> screen can be done with a maximum 499 bytes "inefficiency" off the end
> of a screen.  If we were to increase jit-lock-chunk-size to, say 2000,
> more of the next screen would be getting fontified, perhaps wastefully.
> I don't know how important this is.  Maybe I should try it.
> 
> Indeed.  With jit-lock-chunk-size at 2000, time-scroll on xdisp.c takes:
> 
> (current code): 16.4s
> (new proposed code): 16.1s
> 
> ..  This speed up may well be particular to CC Mode.
> 
> Let's try jit-lock-chunk-size at 8000:
> 
> (current code): 15.1s
> (new proposed code): 15.1s
> 
> ..  So, yes, it would seem a larger chunk size is advantageous for CC
> Mode.

How large (in lines and columns) is your window?  The above numbers
are only meaningful with the window size.

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Alan Mackenzie]

Hello, Eli.

On Sat, Sep 04, 2021 at 18:36:32 +0300, Eli Zaretskii wrote:
> > Date: Sat, 4 Sep 2021 15:32:57 +0000
> > From: Alan Mackenzie <acm@muc.de>
> > Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org

> > > Maybe to speed things up, another option is to grow the chunk size
> > > a bit.

> > Maybe.  An advantage of a small chunk size is that fontifying a single
> > screen can be done with a maximum 499 bytes "inefficiency" off the end
> > of a screen.  If we were to increase jit-lock-chunk-size to, say 2000,
> > more of the next screen would be getting fontified, perhaps wastefully.
> > I don't know how important this is.  Maybe I should try it.

> > Indeed.  With jit-lock-chunk-size at 2000, time-scroll on xdisp.c takes:

> > (current code): 16.4s
> > (new proposed code): 16.1s

> > ..  This speed up may well be particular to CC Mode.

> > Let's try jit-lock-chunk-size at 8000:

> > (current code): 15.1s
> > (new proposed code): 15.1s

> > ..  So, yes, it would seem a larger chunk size is advantageous for CC
> > Mode.

> How large (in lines and columns) is your window?  The above numbers
> are only meaningful with the window size.

I'm running in a window with 65 lines and 118 columns.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Eli Zaretskii]

> Date: Sat, 4 Sep 2021 15:43:40 +0000
> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > > Indeed.  With jit-lock-chunk-size at 2000, time-scroll on xdisp.c takes:
> 
> > > (current code): 16.4s
> > > (new proposed code): 16.1s
> 
> > > ..  This speed up may well be particular to CC Mode.
> 
> > > Let's try jit-lock-chunk-size at 8000:
> 
> > > (current code): 15.1s
> > > (new proposed code): 15.1s
> 
> > > ..  So, yes, it would seem a larger chunk size is advantageous for CC
> > > Mode.
> 
> > How large (in lines and columns) is your window?  The above numbers
> > are only meaningful with the window size.
> 
> I'm running in a window with 65 lines and 118 columns.

That's significantly larger than the default size.  Can you repeat
your experiments with the default size set by "emacs -Q", for
reference?

Thanks.

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Stefan Monnier]

>> But my understanding of what you're saying is that you don't consider
>> "how `jit-lock-bounds` are used" to be an internal detail.  Instead you
>> consider these to be part of the "protocol" that the writer of client
>> functions needs to know in order for those functions to work correctly.
>> And I can't understand why you'd think that.  I think even in the
>> current situation, none of what we have discussed has prompted a need or
>> desire to change client functions: they're oblivious to the change
>> being discussed.
> We have the reason right before our eyes: what Alan needs to do.  If
> these details are not important, why does he work on changing them?

His change is not to font-lock but to jit-lock.  So it's consistent with
my claim that it's a matter that's internal to jit-lock.

>> If so, could you give some kind of scenario where that could happen?
> Why do I need to come up with a scenario, when it's clear as a day
> that programming blindly to an insufficiently documented interface is
> asking for trouble?

But the change under consideration does not affect the documentation of
the API exposed to client functions, AFAICT.  I'm not asking the author
to program blindly.  I just can't see any reason to specify any more
precisely than saying that BEG...END can be any valid region in the
buffer and that the function can use `jit-lock-bounds` to inform
jit-lock of the region actually handled, where this `jit-lock-bounds`
needs to cover BEG...END but is otherwise optional and only used for
optimization purposes.

[ This is largely consistent with what you wrote in the docstring, so
  it seems we agree on this part.  ]

The precise way in which jit-lock uses this info for optimization
purposes is something that may change (and hence should not be part of
the contract/documentation) as evidenced by the fact that Alan already
has 2 proposed patches that change it in different ways, and I myself
described yet another possible way it could be used.


        Stefan

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Alan Mackenzie]

Hello, Eli.

On Sat, Sep 04, 2021 at 18:48:12 +0300, Eli Zaretskii wrote:
> > Date: Sat, 4 Sep 2021 15:43:40 +0000
> > Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > > Indeed.  With jit-lock-chunk-size at 2000, time-scroll on xdisp.c takes:

> > > > (current code): 16.4s
> > > > (new proposed code): 16.1s

> > > > ..  This speed up may well be particular to CC Mode.

> > > > Let's try jit-lock-chunk-size at 8000:

> > > > (current code): 15.1s
> > > > (new proposed code): 15.1s

> > > > ..  So, yes, it would seem a larger chunk size is advantageous for CC
> > > > Mode.

> > > How large (in lines and columns) is your window?  The above numbers
> > > are only meaningful with the window size.

> > I'm running in a window with 65 lines and 118 columns.

> That's significantly larger than the default size.  Can you repeat
> your experiments with the default size set by "emacs -Q", for
> reference?

My previous timings were on a Linux console tty.  Moving to X, and
starting Emacs with emacs --no-desktop, I get 34 Lines and 80 columns.
With my new propose jit-lock code I get the following timings with these
jit-lock-chunk-sizes:

(500): 24.5s
(2000): 18.0s
(8000): 16.4s

..  So it would seem, at least in CC Mode, a larger jit-lock-chunk-size is
advantageous on a default size GUI Emacs, too.

I haven't measured it, but I suspect 8000 would make the display of a
single screen slower, because ~4 screens will be getting fontified per
chunk (at default screen size).  2000 might well be worth going for.

> Thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Stefan Monnier]

>> > , it takes 27.9s.  So it would seem the cost of having a jit-lock
>> > function returning a jit-lock-bounds structure when it's not the first
>> > function is high.  That's using the strategy of a full refontification of
>> > the "extra" regions of the buffer returned in that structure.
>> How does it compare to the performance with the old/current
>> jit-lock code?
> That takes ~22.6s.

And I guess the order makes no difference there?
What about with the simpler patch that passes the bounds of the first
function to the subsequent ones?  I suspect this should give us
something like 21.2s when the ordering is favorable and 22.6s when the
ordering is not, right?

> Maybe.  An advantage of a small chunk size is that fontifying a single
> screen can be done with a maximum 499 bytes "inefficiency" off the end
> of a screen.

[ Well, 499 plus the effect of increasing the specified region by
  rounding it up to whole lines and things like that, of course ;-)  ]

> If we were to increase jit-lock-chunk-size to, say 2000, more of the
> next screen would be getting fontified, perhaps wastefully.

Indeed, I was thinking of increasing it only to 1000.

> Indeed.  With jit-lock-chunk-size at 2000, time-scroll on xdisp.c takes:
>
> (current code): 16.4s
> (new proposed code): 16.1s

A larger chunk should also make the impact of the order of the functions
less important (because the "excess" work returned in `jit-lock-bounds`
should be largely independent from the size of the region).


        Stefan

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: acm@muc.de,  emacs-devel@gnu.org
> Date: Sat, 04 Sep 2021 11:55:08 -0400
> 
> >> But my understanding of what you're saying is that you don't consider
> >> "how `jit-lock-bounds` are used" to be an internal detail.  Instead you
> >> consider these to be part of the "protocol" that the writer of client
> >> functions needs to know in order for those functions to work correctly.
> >> And I can't understand why you'd think that.  I think even in the
> >> current situation, none of what we have discussed has prompted a need or
> >> desire to change client functions: they're oblivious to the change
> >> being discussed.
> > We have the reason right before our eyes: what Alan needs to do.  If
> > these details are not important, why does he work on changing them?
> 
> His change is not to font-lock but to jit-lock.  So it's consistent with
> my claim that it's a matter that's internal to jit-lock.
> 
> >> If so, could you give some kind of scenario where that could happen?
> > Why do I need to come up with a scenario, when it's clear as a day
> > that programming blindly to an insufficiently documented interface is
> > asking for trouble?
> 
> But the change under consideration does not affect the documentation of
> the API exposed to client functions, AFAICT.  I'm not asking the author
> to program blindly.  I just can't see any reason to specify any more
> precisely than saying that BEG...END can be any valid region in the
> buffer and that the function can use `jit-lock-bounds` to inform
> jit-lock of the region actually handled, where this `jit-lock-bounds`
> needs to cover BEG...END but is otherwise optional and only used for
> optimization purposes.
> 
> [ This is largely consistent with what you wrote in the docstring, so
>   it seems we agree on this part.  ]
> 
> The precise way in which jit-lock uses this info for optimization
> purposes is something that may change (and hence should not be part of
> the contract/documentation) as evidenced by the fact that Alan already
> has 2 proposed patches that change it in different ways, and I myself
> described yet another possible way it could be used.

Let's agree to disagree about this, okay?

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Eli Zaretskii]

> Date: Sat, 4 Sep 2021 16:05:44 +0000
> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> My previous timings were on a Linux console tty.  Moving to X, and
> starting Emacs with emacs --no-desktop, I get 34 Lines and 80 columns.
> With my new propose jit-lock code I get the following timings with these
> jit-lock-chunk-sizes:
> 
> (500): 24.5s
> (2000): 18.0s
> (8000): 16.4s
> 
> ..  So it would seem, at least in CC Mode, a larger jit-lock-chunk-size is
> advantageous on a default size GUI Emacs, too.

Yes, I guess we should increase the default.

Thanks.

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Sat, 04 Sep 2021 12:06:44 -0400
> 
> > Maybe.  An advantage of a small chunk size is that fontifying a single
> > screen can be done with a maximum 499 bytes "inefficiency" off the end
> > of a screen.
> 
> [ Well, 499 plus the effect of increasing the specified region by
>   rounding it up to whole lines and things like that, of course ;-)  ]
> 
> > If we were to increase jit-lock-chunk-size to, say 2000, more of the
> > next screen would be getting fontified, perhaps wastefully.
> 
> Indeed, I was thinking of increasing it only to 1000.

To see the "waste" in single-windowful scrolls, we need a suitable
benchmark, which measures the time of each scroll separately.  It
would probably make sense to make it generate a random value of point,
then measure the time it takes to go there and display.

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Stefan Monnier]

> Let's agree to disagree about this, okay?

I'm not even sure we disagree: my questions are just trying to
understand what you mean to document, how you mean to document it, and
why you think it's important.


        Stefan

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: acm@muc.de,  emacs-devel@gnu.org
> Date: Sat, 04 Sep 2021 12:24:40 -0400
> 
> > Let's agree to disagree about this, okay?
> 
> I'm not even sure we disagree: my questions are just trying to
> understand what you mean to document, how you mean to document it, and
> why you think it's important.

I tried to explain it many times, and evidently failed.  Perhaps
because I'm surprised I need to explain something like that.

Sorry.

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Stefan Monnier]

> To see the "waste" in single-windowful scrolls, we need a suitable
> benchmark, which measures the time of each scroll separately.  It
> would probably make sense to make it generate a random value of point,
> then measure the time it takes to go there and display.

Maybe a good way to see the waste is to measure the time for the initial
font-lock in an outline-mode buffer where the screen is filled with
single-line headers and everything else is hidden: a whole chunk will be
fontified for each line, so with a single 40-line screen you can expect
to fontify 40 chunks (unless the hidden text between lines is smaller
than the chunk size, of course).


        Stefan


PS: For the record, I was made aware of this case back in the days of
lazy-lock because lazy-lock didn't know how to skip invisible text (it
just fontified everything between window-start and window-end), so in
some cases it would end up fontifying the whole buffer.

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Stefan Monnier]

> I tried to explain it many times, and evidently failed.  Perhaps
> because I'm surprised I need to explain something like that.

That's why I think it's likely a misunderstanding: for both of us the
other's position is completely opposed to something we take as obvious.


        Stefan

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: acm@muc.de,  emacs-devel@gnu.org
> Date: Sat, 04 Sep 2021 12:39:09 -0400
> 
> > To see the "waste" in single-windowful scrolls, we need a suitable
> > benchmark, which measures the time of each scroll separately.  It
> > would probably make sense to make it generate a random value of point,
> > then measure the time it takes to go there and display.
> 
> Maybe a good way to see the waste is to measure the time for the initial
> font-lock in an outline-mode buffer where the screen is filled with
> single-line headers and everything else is hidden: a whole chunk will be
> fontified for each line, so with a single 40-line screen you can expect
> to fontify 40 chunks (unless the hidden text between lines is smaller
> than the chunk size, of course).
> 
> 
>         Stefan
> 
> 
> PS: For the record, I was made aware of this case back in the days of
> lazy-lock because lazy-lock didn't know how to skip invisible text (it
> just fontified everything between window-start and window-end), so in
> some cases it would end up fontifying the whole buffer.

You are saying that jit-lock skips invisible text?  I don't think I
see this in the code.

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Stefan Monnier]

>> PS: For the record, I was made aware of this case back in the days of
>> lazy-lock because lazy-lock didn't know how to skip invisible text (it
>> just fontified everything between window-start and window-end), so in
>> some cases it would end up fontifying the whole buffer.
>
> You are saying that jit-lock skips invisible text?

Indeed, tho `jit-lock.el` itself makes no effort to skip invisible text.

> I don't think I see this in the code.

IIRC it's a result of the redisplay skipping invisible text and hence not
calling `fontification-functions` on it.


        Stefan

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: acm@muc.de,  emacs-devel@gnu.org
> Date: Sat, 04 Sep 2021 13:47:09 -0400
> 
> IIRC it's a result of the redisplay skipping invisible text and hence not
> calling `fontification-functions` on it.

My reading of the xdisp.c code is that it first invokes
fontification-functions, and only after that checks for invisible
text.  See handle_stop and the way it iterates over the handlers in
the it_props array.

Do you have some Lisp to show that invisible text isn't fontified by
jit-lock?

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Stefan Monnier]

> Do you have some Lisp to show that invisible text isn't fontified by
> jit-lock?

    src/emacs -Q lisp/subr.el -f outline-minor-mode --eval '(hide-sublevels 1)'

then go to the line that says "subr.el ends here" and do

    M-: (get-text-property (- (point) 10) 'fontified) RET

and it will probably say nil.


        Stefan


PS: My own config enables `outline-minor-mode` and calls
`hide-sublevels` in a similar way, so I'd notice the performance
difference if the whole buffer were fontified ;-)

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Alan Mackenzie]

Hello, Eli and Stefan.

On Sat, Sep 04, 2021 at 19:15:08 +0300, Eli Zaretskii wrote:
> > Date: Sat, 4 Sep 2021 16:05:44 +0000
> > Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > My previous timings were on a Linux console tty.  Moving to X, and
> > starting Emacs with emacs --no-desktop, I get 34 Lines and 80 columns.
> > With my new propose jit-lock code I get the following timings with these
> > jit-lock-chunk-sizes:

> > (500): 24.5s
> > (2000): 18.0s
> > (8000): 16.4s

> > ..  So it would seem, at least in CC Mode, a larger jit-lock-chunk-size is
> > advantageous on a default size GUI Emacs, too.

> Yes, I guess we should increase the default.

I think the optimal size for jit-lock-chunk-size is a little over how
much text fits in a window.  That way, an entire window can be fontified
in a single chunk, minimising overhead.  However, much more than that,
and the fontification is less JIT, more like fontifying large chunks of
a buffer just in case.

So, I propose a default value of 2000.  Approximately 1700 characters of
xdisp.c fit into a default sized GUI window.  I think the doc string
should say a little more.

So, how about:



diff --git a/lisp/jit-lock.el b/lisp/jit-lock.el
index a1287926eb..4c612a6398 100644
--- a/lisp/jit-lock.el
+++ b/lisp/jit-lock.el
@@ -44,10 +44,13 @@ jit-lock
   :version "21.1"
   :group 'font-lock)
 
-(defcustom jit-lock-chunk-size 500
+(defcustom jit-lock-chunk-size 2000
   "Jit-lock fontifies chunks of at most this many characters at a time.
 
-This variable controls both display-time and stealth fontification."
+This variable controls both display-time and stealth fontification.
+
+The optimum value is a little over the typical number of buffer
+characters which fit in a window."
   :type 'integer)
 
 


> Thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Eli Zaretskii]

> Date: Mon, 6 Sep 2021 10:46:48 +0000
> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> I think the optimal size for jit-lock-chunk-size is a little over how
> much text fits in a window.  That way, an entire window can be fontified
> in a single chunk, minimising overhead.  However, much more than that,
> and the fontification is less JIT, more like fontifying large chunks of
> a buffer just in case.
> 
> So, I propose a default value of 2000.  Approximately 1700 characters of
> xdisp.c fit into a default sized GUI window.

Not here.  I only get 1300.

In any case, can we please perform the single-windowful scroll
benchmark before making the decision?  Doing this stuff from intuition
is known to be a bad idea.

> +The optimum value is a little over the typical number of buffer
> +characters which fit in a window."

"in a typical window", probably, since not all windows are created
equal, and in general the frames aren't always single-windowed.

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Stefan Monnier]

> I think the optimal size for jit-lock-chunk-size is a little over how
> much text fits in a window.  That way, an entire window can be fontified
> in a single chunk, minimising overhead.  However, much more than that,
> and the fontification is less JIT, more like fontifying large chunks of
> a buffer just in case.

You might be right, but really I don't know and I think no one does.

E.g. Scrolling is an important case, indeed, but in the case where the
user only scrolls one-screenful it might not be terribly important if we
take a bit more time than strictly necessary (as long as it doesn't
affect the responsiveness perceived by the user), whereas in the case
where the user will scroll several screenfuls, it might be worthwhile to
font-lock 2 or 3 screenfuls at a time if it increases the throughput
sufficiently to keep up with the repeat rate.

Also there are other very common cases where a significantly smaller
amount of new text becomes visible (e.g. in response to
a `delete-region`, or point movement which causes some recentering to
keep point visible, maybe even with `scroll-conservatively`).

In my mind, the optimal size depends on the details of the client
function's cost which will likely take a form like `a + b*x` where `x`
is the size of the chunk.  In that case, the optimal chunk size is
a tradeoff between wasted work `b*x` for too large chunks and excessive
repetitions of `a` for too small chunks.

Disregarding the case of invisible text, let's assume that there's only
going to be one call of the client function which will result in wasted
work (go past `window-end`) in a given redisplay (for a specific
window).  So the main downside of increasing the chunk size is the
increase of latency of a single redisplay by `b*x` where `x` is the
excess amount of the last chunk.  As long as this `b*x` is small (at
the human scale), then I think it's harmless.

So maybe we should measure the "average worst case" time to fontify
a chunk for different sizes (i.e. measure the average cost on a slow
machine for a large buffer using a major mode where fontification is
known to be expensive, e.g. using things like (c)perl-mode, or
c++-mode), and then decide how much latency we're willing to pay: that
might give us a "sound" basis to choose the chunk size.


        Stefan

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Alan Mackenzie]

Hello, Eli.

On Mon, Sep 06, 2021 at 14:10:54 +0300, Eli Zaretskii wrote:
> > Date: Mon, 6 Sep 2021 10:46:48 +0000
> > Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > I think the optimal size for jit-lock-chunk-size is a little over how
> > much text fits in a window.  That way, an entire window can be fontified
> > in a single chunk, minimising overhead.  However, much more than that,
> > and the fontification is less JIT, more like fontifying large chunks of
> > a buffer just in case.

> > So, I propose a default value of 2000.  Approximately 1700 characters of
> > xdisp.c fit into a default sized GUI window.

> Not here.  I only get 1300.

Sorry.  Slip between brain and keyboard.

> In any case, can we please perform the single-windowful scroll
> benchmark before making the decision?  Doing this stuff from intuition
> is known to be a bad idea.

From another post, you wrote:
>>> To see the "waste" in single-windowful scrolls, we need a suitable
>>> benchmark, which measures the time of each scroll separately.  It
>>> would probably make sense to make it generate a random value of
>>> point, then measure the time it takes to go there and display.

So I hacked together a quick benchmark chunk-size-benchmark, which takes
a single argument, the jit-lock-chunk-size, and then in the current
window and buffer moves successively to 10%, 20%, 30%, ...., 90% through
the buffer and waits for fontification.  The average of those ten values
is output to the *Messages* buffer.

Then I wrote a variation, which jumps to a 10x% position in the buffer,
waits for fontification, then scrolls forward a screen and waits again
for fontification.  The average value is, again, printed out.

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(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)))

(defun chunk-size-benchmark (chunk-size)
  (interactive "p")
  (if (< chunk-size 100) (error "chunk-size, %s, is less than 100" chunk-size))
  (widen)
  (let ((jit-lock-chunk-size chunk-size)
	(buf-size (point-max))
	this-time (total 0)
	)
    (dolist (i '(0 1 2 3 4 5 6 7 8 9))
      (font-lock-flush)
      (setq this-time
	    (time-it (goto-char (1+ (/ (* i buf-size) 10)))
		     (sit-for 0)))
      (setq total (+ total this-time)))
    (message "Average time for chunk-size %s is %s" chunk-size (/ total 10))))
	
	
(defun chunk-size-benchmark-2 (chunk-size)
  (interactive "p")
  (if (< chunk-size 100) (error "chunk-size, %s, is less than 100" chunk-size))
  (widen)
  (let ((jit-lock-chunk-size chunk-size)
	(buf-size (point-max))
	this-time (total 0)
	)
    (dolist (i '(0 1 2 3 4 5 6 7 8 9))
      (font-lock-flush)
      (setq this-time
	    (time-it (goto-char (1+ (/ (* i buf-size) 10)))
		     (sit-for 0)
		     (scroll-up)
		     (sit-for 0)))
      (setq total (+ total this-time)))
    (message "Average time for two chunk-size %s is %s" chunk-size (/ total 10))))
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

I got these timings, using xdisp.c each time:

(i) On a 65 line window on a Linux console tty:
Average time for chunk-size 500 is 0.09474895000457764
Average time for chunk-size 1000 is 0.08993968963623047
Average time for chunk-size 1500 is 0.07838799953460693
Average time for chunk-size 2000 is 0.0901902437210083
Average time for chunk-size 2500 is 0.09380950927734374
Average time for chunk-size 3000 is 0.09139835834503174
Average time for chunk-size 3500 is 0.09265313148498536
Average time for chunk-size 4000 is 0.09945495128631592

Average time for two chunk-size 500 is 0.14148397445678712
Average time for two chunk-size 1000 is 0.11814579963684083
Average time for two chunk-size 1500 is 0.11486186981201171
Average time for two chunk-size 2000 is 0.12313232421875
Average time for two chunk-size 2500 is 0.12045748233795166
Average time for two chunk-size 3000 is 0.1140979528427124
Average time for two chunk-size 3500 is 0.10788719654083252
Average time for two chunk-size 4000 is 0.11099658012390137

(ii) On a 34 line window (default size) in X Windows:
Average time for chunk-size 500 is 0.06480436325073242
Average time for chunk-size 1000 is 0.06025857925415039
Average time for chunk-size 1500 is 0.06389858722686767
Average time for chunk-size 2000 is 0.06813716888427734
Average time for chunk-size 2500 is 0.07740669250488282
Average time for chunk-size 3000 is 0.0859900712966919
Average time for chunk-size 3500 is 0.09434397220611572
Average time for chunk-size 4000 is 0.10622837543487548

Average time for two chunk-size 500 is 0.09408855438232422
Average time for two chunk-size 1000 is 0.08264987468719483
Average time for two chunk-size 1500 is 0.08883922100067139
Average time for two chunk-size 2000 is 0.07863264083862305
Average time for two chunk-size 2500 is 0.08350887298583984
Average time for two chunk-size 3000 is 0.08896465301513672
Average time for two chunk-size 3500 is 0.09870367050170899
Average time for two chunk-size 4000 is 0.10917885303497314

(iii) On a 54 line window in X Windows:
Average time for chunk-size 500 is 0.11301305294036865
Average time for chunk-size 1000 is 0.10326454639434815
Average time for chunk-size 1500 is 0.10011684894561768
Average time for chunk-size 2000 is 0.10956480503082275
Average time for chunk-size 2500 is 0.11465866565704345
Average time for chunk-size 3000 is 0.12143938541412354
Average time for chunk-size 3500 is 0.13569414615631104
Average time for chunk-size 4000 is 0.15041179656982423

Average time for two chunk-size 500 is 0.16088194847106935
Average time for two chunk-size 1000 is 0.14736626148223878
Average time for two chunk-size 1500 is 0.13186230659484863
Average time for two chunk-size 2000 is 0.14865143299102784
Average time for two chunk-size 2500 is 0.13905446529388427
Average time for two chunk-size 3000 is 0.13570570945739746
Average time for two chunk-size 3500 is 0.14243290424346924
Average time for two chunk-size 4000 is 0.15591373443603515

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

So, I would reason as follows:
(i) 500 bytes is too small.
(ii) We should be more concerned about the timings on larger windows, if
we are concerned about redisplay times.  0.1s (for a 54 line window) is
appreciably greater than 0.06s (a 34 line window), which is on the point
of seeming instantaneous.
(iii) The two chunk-size time on 54 lines suggests an optimum of 1500,
which is supported by the corresponding times on the tty.
(iv) 1500 is not far from optimal on 34 lines single chunk, though not
so for the two chunk time.

(It is notable that redisplay is quite a bit slower in X at 54 lines
than on a Linux console at 65 lines.)

So, based on these timings, I would suggest a new jit-lock-chunk-size of
1500.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Eli Zaretskii]

> Date: Mon, 6 Sep 2021 19:08:45 +0000
> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> (It is notable that redisplay is quite a bit slower in X at 54 lines
> than on a Linux console at 65 lines.)

That's expected: TTY display skips some stuff that is only needed on
GUI frames, so it's faster.

> So, based on these timings, I would suggest a new jit-lock-chunk-size of
> 1500.

Agreed.  Please be sure to include a reference to this message in the
commit log message, when you install the change.

Thanks.

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[andrés ramírez]

Hi. Alan.

>>>>> "Alan" == Alan Mackenzie <acm@muc.de> writes:

[...]


    Alan> (It is notable that redisplay is quite a bit slower in X at 54 lines than on a Linux
    Alan> console at 65 lines.)

Is this on proper emacs frame? or is this on tty within xterm?

Best Regards

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[andrés ramírez]

Hi. Alan.

>>>>> "Alan" == Alan Mackenzie <acm@muc.de> writes:


[...]

    Alan> (It is notable that redisplay is quite a bit slower in X at 54 lines than on a Linux
    Alan> console at 65 lines.)

    >> Is this on proper emacs frame? or is this on tty within xterm?

    Alan> This was on a full GUI frame.  I didn't do any timings on an xterm.  Perhaps I should have
    Alan> done.

    Alan> Feel free to fill in the gap.  ;-).

I have done it in the past:

1 lucid-frame {normal performance}
2 tty-frame within xterm {performance is better than normal}
3 fbcon {You could get the best results here}

Most of my time within emacs is spend on (2). When I deal with
media-files {pdf, images} number (1). There is no other option. And when
You want to get the best fbcon (3). This is just for my case on a
quad-core arm machine {orange pi plus 2e}.

Best Regards

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Alan Mackenzie]

Hello, Andrés.

On Mon, Sep 06, 2021 at 21:59:04 +0000, andrés ramírez wrote:
> Hi. Alan.

> >>>>> "Alan" == Alan Mackenzie <acm@muc.de> writes:

> [...]


>     Alan> (It is notable that redisplay is quite a bit slower in X at 54 lines than on a Linux
>     Alan> console at 65 lines.)

> Is this on proper emacs frame? or is this on tty within xterm?

This was on a full GUI frame.  I didn't do any timings on an xterm.
Perhaps I should have done.

Feel free to fill in the gap.  ;-).

> Best Regards

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: acm@muc.de,  emacs-devel@gnu.org
> Date: Sat, 04 Sep 2021 14:40:16 -0400
> 
> > Do you have some Lisp to show that invisible text isn't fontified by
> > jit-lock?
> 
>     src/emacs -Q lisp/subr.el -f outline-minor-mode --eval '(hide-sublevels 1)'
> 
> then go to the line that says "subr.el ends here" and do
> 
>     M-: (get-text-property (- (point) 10) 'fontified) RET
> 
> and it will probably say nil.

That's sheer luck: it happens only when the invisible text between
headings is longer than jit-lock-chunk-size.

What happens is this:

  . redisplay invokes jit-lock, which fontifies jit-lock-chunk-size
    characters;
  . redisplay discovers the invisible text, and skips to its end;
  . redisplay once again invokes jit-lock after skipping invisible
    text;

etc., etc., until we reach the end of the window (which in the above
case means EOB).

So what you get is 1500 characters after each heading fontified, the
rest not fontified.  E.g., try your get-text-property trick on
headings other than the last one.

> PS: My own config enables `outline-minor-mode` and calls
> `hide-sublevels` in a similar way, so I'd notice the performance
> difference if the whole buffer were fontified ;-)

If you hide a lot of text, then yes, only parts of it will be
fontified.

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Stefan Monnier]

>> and it will probably say nil.
> That's sheer luck: it happens only when the invisible text between
> headings is longer than jit-lock-chunk-size.

That was exactly the case I was talking about.
That's why I wrote a few messages ago:

    Maybe a good way to see the waste is to measure the time for the
    initial font-lock in an outline-mode buffer where the screen is
    filled with single-line headers and everything else is hidden:
    a whole chunk will be fontified for each line, so with a single
    40-line screen you can expect to fontify 40 chunks (unless the
    hidden text between lines is smaller than the chunk size, of
    course).


-- Stefan

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: acm@muc.de,  emacs-devel@gnu.org
> Date: Sat, 11 Sep 2021 13:04:31 -0400
> 
> >> and it will probably say nil.
> > That's sheer luck: it happens only when the invisible text between
> > headings is longer than jit-lock-chunk-size.
> 
> That was exactly the case I was talking about.
> That's why I wrote a few messages ago:
> 
>     Maybe a good way to see the waste is to measure the time for the
>     initial font-lock in an outline-mode buffer where the screen is
>     filled with single-line headers and everything else is hidden:
>     a whole chunk will be fontified for each line, so with a single
>     40-line screen you can expect to fontify 40 chunks (unless the
>     hidden text between lines is smaller than the chunk size, of
>     course).

That's okay, but the thing is we do fontify invisible text, and 1500
characters could be easily 40 lines, so the probability of more than
that to be hidden is not large, except in unusual cases like reading
Lisp in Outline mode with all the code hidden.

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Stefan Monnier]

>>     Maybe a good way to see the waste is to measure the time for the
>>     initial font-lock in an outline-mode buffer where the screen is
>>     filled with single-line headers and everything else is hidden:
>>     a whole chunk will be fontified for each line, so with a single
>>     40-line screen you can expect to fontify 40 chunks (unless the
>>     hidden text between lines is smaller than the chunk size, of
>>     course).
>
> That's okay, but the thing is we do fontify invisible text, and 1500
> characters could be easily 40 lines, so the probability of more than
> that to be hidden is not large, except in unusual cases like reading
> Lisp in Outline mode with all the code hidden.

Where, your "unusual" is my default, so I'm quite happy that jit-lock
optimizes this case ;-)


        Stefan

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: acm@muc.de,  emacs-devel@gnu.org
> Date: Sat, 11 Sep 2021 14:00:57 -0400
> 
> >>     Maybe a good way to see the waste is to measure the time for the
> >>     initial font-lock in an outline-mode buffer where the screen is
> >>     filled with single-line headers and everything else is hidden:
> >>     a whole chunk will be fontified for each line, so with a single
> >>     40-line screen you can expect to fontify 40 chunks (unless the
> >>     hidden text between lines is smaller than the chunk size, of
> >>     course).
> >
> > That's okay, but the thing is we do fontify invisible text, and 1500
> > characters could be easily 40 lines, so the probability of more than
> > that to be hidden is not large, except in unusual cases like reading
> > Lisp in Outline mode with all the code hidden.
> 
> Where, your "unusual" is my default

With all the code hidden? really?  Why have that in Emacs at all, if
you aren't editing its code?

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Stefan Monnier]

>> Where, your "unusual" is my default
> With all the code hidden? really?

Yup, my outline-minor-mode-hook calls (hide-sublevels 1)
and I activate `outline-minor-mode` in my `emacs-lisp-mode-hook`.


        Stefan

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: acm@muc.de,  emacs-devel@gnu.org
> Date: Sat, 11 Sep 2021 15:55:52 -0400
> 
> >> Where, your "unusual" is my default
> > With all the code hidden? really?
> 
> Yup, my outline-minor-mode-hook calls (hide-sublevels 1)
> and I activate `outline-minor-mode` in my `emacs-lisp-mode-hook`.

So you never edit the code of Lisp files you visit?

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Stefan Monnier]

>> >> Where, your "unusual" is my default
>> > With all the code hidden? really?
>> Yup, my outline-minor-mode-hook calls (hide-sublevels 1)
>> and I activate `outline-minor-mode` in my `emacs-lisp-mode-hook`.
> So you never edit the code of Lisp files you visit?

`outline-minor-mode` doesn't prevent you from editing the code (nor from
seeing it).  You just have to reveal it beforehand, which you can do with
the various outline-show-* commands, tho I rely on
`reveal-mode` instead.


        Stefan

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: acm@muc.de,  emacs-devel@gnu.org
> Date: Sun, 12 Sep 2021 12:41:47 -0400
> 
> >> >> Where, your "unusual" is my default
> >> > With all the code hidden? really?
> >> Yup, my outline-minor-mode-hook calls (hide-sublevels 1)
> >> and I activate `outline-minor-mode` in my `emacs-lisp-mode-hook`.
> > So you never edit the code of Lisp files you visit?
> 
> `outline-minor-mode` doesn't prevent you from editing the code (nor from
> seeing it).  You just have to reveal it beforehand, which you can do with
> the various outline-show-* commands, tho I rely on
> `reveal-mode` instead.

Yes, of course.  Which is why I think that having the entire code
hidden is a rare phenomenon, even in your sessions.  Because once you
visit a file, you usually reveal the code, in order to work on it.

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Stefan Monnier]

> Yes, of course.  Which is why I think that having the entire code
> hidden is a rare phenomenon, even in your sessions.  Because once you
> visit a file, you usually reveal the code, in order to work on it.

Right, but the big gain is right when I open the file, where jit-lock
only fontifies a handful of chunks even though often both point-min and
point-max are visible.


        Stefan

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: acm@muc.de,  emacs-devel@gnu.org
> Date: Sun, 12 Sep 2021 13:41:05 -0400
> 
> > Yes, of course.  Which is why I think that having the entire code
> > hidden is a rare phenomenon, even in your sessions.  Because once you
> > visit a file, you usually reveal the code, in order to work on it.
> 
> Right, but the big gain is right when I open the file, where jit-lock
> only fontifies a handful of chunks even though often both point-min and
> point-max are visible.

I think the gain is illusory, because as soon as you unhide the code,
we start fontifying everything as usual.  IOW, hiding text is for this
purpose the same as simply leaving it off-screen.

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Stefan Monnier]

>> Right, but the big gain is right when I open the file, where jit-lock
>> only fontifies a handful of chunks even though often both point-min and
>> point-max are visible.
> I think the gain is illusory,

No, it makes the buffer display "instantly" instead of taking a few
seconds to highlight it from head to toe.

> because as soon as you unhide the code, we start fontifying everything
> as usual.

Just the "one screenful" at a time, so still "instantly".

IOW, it makes it work like "jit" intends.

> IOW, hiding text is for this purpose the same as simply
> leaving it off-screen.

I don't know what you mean by that.  I use `outline-minor-mode` because
I like the way it gives me an overview of the whole buffer (akin to an
"in-buffer speedbar"), not because of its interaction with
jit/font-lock performance.


        Stefan

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Alan Mackenzie]

Hello, Eli.

On Mon, Sep 06, 2021 at 22:23:01 +0300, Eli Zaretskii wrote:
> > Date: Mon, 6 Sep 2021 19:08:45 +0000
> > Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > (It is notable that redisplay is quite a bit slower in X at 54 lines
> > than on a Linux console at 65 lines.)

> That's expected: TTY display skips some stuff that is only needed on
> GUI frames, so it's faster.

> > So, based on these timings, I would suggest a new jit-lock-chunk-size of
> > 1500.

> Agreed.  Please be sure to include a reference to this message in the
> commit log message, when you install the change.

> Thanks.

Just as a postscript, the 7% speed advantage from reworked jit code we
were talking about has largely disappeared with the increase in
jit-chunk-size from 500 to 1500.  The speed advantage is now around 1% -
2%, almost, but not quite, lost in the noise.

I therefore propose not installing any of these changes for Emacs-28.  I
don't think the slight speed increase would justify the increased
complexity.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Eli Zaretskii]

> Date: Sat, 18 Sep 2021 11:37:32 +0000
> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> Just as a postscript, the 7% speed advantage from reworked jit code we
> were talking about has largely disappeared with the increase in
> jit-chunk-size from 500 to 1500.  The speed advantage is now around 1% -
> 2%, almost, but not quite, lost in the noise.
> 
> I therefore propose not installing any of these changes for Emacs-28.  I
> don't think the slight speed increase would justify the increased
> complexity.

Fine with me, thanks.