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

Previous Next

Full log

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: yantar92 <at> posteo.net, Stefan Monnier <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: Thu, 24 Apr 2025 07:42:21 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
>> Cc: gerd.moellmann <at> gmail.com,  stefankangas <at> gmail.com,
>> 	77924 <at> debbugs.gnu.org, Ihor Radchenko <yantar92 <at> posteo.net>
>> Date: Wed, 23 Apr 2025 11:41:43 -0400
>> 
>> > Btw, did I miss some benchmarks?  I presume that the main motivation
>> > for this branch is to speed up markers and charpos-to-bytepos
>> > conversions, is that right?  If so, the only benchmark I saw shows only
>> > a very mild speed-up, but maybe I missed something?
>> 
>> AFAICT we have tuned the current charpos<->bytepos conversion code such
>> that its worst case virtually never shows up in practice.
>> 
>> Supposedly Ihor has a use case where that conversion still can make
>> a noticeable difference, but I don't know if he tried the `text-index`
>> branch to confirm that it makes a measurable difference on his case.
>> 
>> Gerd and I played with some micro benchmarks to confirm that the
>> pathological behaviors are indeed solved, but other than that, the focus
>> was on making sure the branch does not make the normal case slower
>> (contrary to my sorted-array-of-markers-with-gap).
>
> Still, for performance-oriented changes, it would be nice to see some
> benchmarks.  Scrolling through some large file with many non-ASCII
> characters comes to mind (the Unicode UCD has quite a few of such
> files).
>
> Also, I believe there were cases where a lot of conversions
> created gobs of markers which slowed down things; it would be good to
> run those cases to see how they are affected.
>
> And finally, how about running the whole benchmark suite we have, in
> case it uncovers some unexpected results?

I can offer to run benchmarks on my Mac mini.

But we should agree upon what elisp-benchmark files I should use and on
the number of runs, because running them takes an eternity, and because
some of the benchmarks Stef (and me for elb-search) ran are not in the
"official" elisp-benchmarks package.

Don't know about the scrolling benchmark. Is what is in elisp-benchmarks
enough? If not, can you please give me a bencnhmark file for what you
want benchmarked?

Previous Next

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