bug#67390: 28; shorthands-font-lock-shorthands assumes shorthand uses same separator

["João Távora" <joaotavora@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2083 bytes --]

On Mon, Nov 27, 2023, 12:12 Eli Zaretskii <eliz@gnu.org> wrote:

> > From: João Távora <joaotavora@gmail.com>
> > Date: Sun, 26 Nov 2023 22:02:01 +0000
> > Cc: Jonas Bernoulli <jonas@bernoul.li>, 67390@debbugs.gnu.org,
> >       Adam Porter <adam@alphapapa.net>
> >
> > On Sun, Nov 26, 2023 at 8:38 PM Joseph Turner <joseph@ushin.org> wrote:
> > >
> > > João Távora <joaotavora@gmail.com> writes:
> > >
> > > > On Sat, Nov 25, 2023 at 10:43 PM Joseph Turner <joseph@ushin.org>
> wrote:
> >
> > > > So, benchmarking it will have to be, I'm afraid, because AFAIK
> > > > font-locking is a very performance sensitive area of Emacs.
> > >
> > > Yes.  I would like to learn how to do this!
> >
> > I'm CCing Eli.
> >
> > In the past, ISTR, Eli suggested to benchmark such things by visiting a
> > very large file in its beginning, then scrolling down by holding
> > the down arrow or PgDn for some fixed time period, like 30 seconds.
> > The  Emacs that scrolls the farthest is the most performant.  Not
> > entirely fail-proof (other processes may interfere, etc), but not
> > bad either.
>
> I still recommend this method.  Something like the below:
>
>   (defun scroll-up-benchmark ()
>     (interactive)
>     (let ((oldgc gcs-done)
>           (oldtime (float-time)))
>       (condition-case nil (while t (scroll-up) (redisplay))
>         (error (message "GCs: %d Elapsed time: %f seconds"
>                         (- gcs-done oldgc) (- (float-time) oldtime))))))
>
> Evaluate the above, and the invoke it at the beginning of a large
> file.  Then compare the timings with different font-lock arrangements.
>
> A variant is to scroll by N lines, not by pages.  Just change the
> above to call scroll-up with the argument of N, for example 1 (or any
> other number, if you want).
>

Joseph can you try these variations? They're slightly more exact. Also show
at least one of the large lisp files or tell me how to generate one. If you
still don't find any significant slowdown, I think we can merge your patch.

João

>

[-- Attachment #2: Type: text/html, Size: 3396 bytes --]