GNU bug report logs - #77924
31.0.50; [Feature branch] Change marker implementation

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: yantar92 <at> posteo.net, monnier <at> iro.umontreal.ca, 77924 <at> debbugs.gnu.org,
 stefankangas <at> gmail.com
Subject: Re: bug#77924: 31.0.50; [Feature branch] Change marker implementation
Date: Fri, 25 Apr 2025 09:25:29 +0300

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  stefankangas <at> gmail.com,
>   77924 <at> debbugs.gnu.org,  yantar92 <at> posteo.net
> Date: Thu, 24 Apr 2025 18:32:00 +0200
> 
> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> 
> >>> Evaluate this, then invoke "M-x scroll-up-benchmark" in a large buffer
> >>> with lots of non-ASCII characters.  Compare the timings between the
> >>> two versions of Emacs.
> >>
> >> elb-scroll from elisp-bechmarks is basically
> >>
> >>       (dotimes (_ 10)
> >>         (elb-smie-mode)
> >>         (goto-char (point-min))
> >>         (condition-case nil
> >>             (while t (scroll-up nil) (redisplay 'force))
> >>           (end-of-buffer nil))))))
> >>
> >> looks similar, but I don't know what elb-smie-mode does.
> >
> > It's a major mode for the C language, separate from CC-mode.
> > [ It's basically "vendored" copy of the `sm-c-mode` that's on GNU
> > ELPA.  ]
> 
> Ah, interesting. 
> 
> > So the benchmark tests scroll time, including jit/font-lock time.
> > It uses its own copy of a major mode, so that you can compare "scroll +
> > font-lock" performance between different Emacs releases without being
> > affected by improvements/regressions in CC-mode itself.
> 
> So maybe it would make sense to run both that benchmark as-is plus one
> without smie but with tamil.txt, I guess. Or in other words, now only
> the as-is benchmark, because the tamil.txt results I've already posted.

Scrolling through tamil.txt and any other similar text file needs a
benchmark that doesn't require sm-c-mode, because these are usually
not C source files, and OTOH C source files rarely include many
non-ASCII characters, let alone Tamil or something like that.

And one more thing, because I'm not familiar with how the benchmark
suite is run: the scroll benchmarks must be run interactively, because
otherwise we are at best exercising the TTY redisplay, and at worst
don't exercise redisplay at all, since nothing is being displayed.
The charpos-to-bytepos conversions are used a lot in the display code,
so we must let redisplay work for this to be a meaningful benchmark.

Previous Next

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