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

Previous Next

Package: emacs;

Reported by: Gerd Möllmann <gerd.moellmann <at> gmail.com>

Date: Sat, 19 Apr 2025 16:06:02 UTC

Severity: normal

Found in version 31.0.50

Full log


View this message in rfc822 format

From: Visuwesh <visuweshm <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, yantar92 <at> posteo.net, Stefan Monnier <monnier <at> iro.umontreal.ca>, 77924 <at> debbugs.gnu.org, stefankangas <at> gmail.com
Subject: bug#77924: 31.0.50; [Feature branch] Change marker implementation
Date: Thu, 24 Apr 2025 11:31:33 +0530
[வியாழன் ஏப்ரல் 24, 2025] Eli Zaretskii wrote:

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

Is there a standard benchmark code that I can try for this?  I have such
a large HTML file with Tamil text, and I can scroll through the buffer
produced by shr-render-buffer.




This bug report was last modified 105 days ago.

Previous Next


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