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

Previous Next

Full log

View this message in rfc822 format

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: pipcet <at> protonmail.com, 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: Fri, 25 Apr 2025 14:22:30 +0200

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

>> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> Cc: pipcet <at> protonmail.com,  monnier <at> iro.umontreal.ca,
>>   77924 <at> debbugs.gnu.org,  stefankangas <at> gmail.com
>> Date: Fri, 25 Apr 2025 13:40:47 +0200
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> > Actually, I thought about maintaining the number of markers in the
>> > vector, so there would be no need to detect that by the MARKERP test.
>> 
>> Not sure how that would work, but maybe you are thinking of the LRU list
>> in igc.
>
> We were talking about different aspects, sorry.
>
> Regarding the issue with a marker vector where some slots are free, we
> could simply compare with NULL.  Or we could keep a pointer to the
> next non-free slot.  Not sure what should be cheaper, since iteration
> over all the markers is quite frequent, whereas adding and removing
> markers is probably less so.
>
>> Iteration is done by stepping over all _ and M in order (= fast), and
>> only giving out at the M entries. And as a small optimization for the
>> case of over-allocation, I remember the max index of an M that was ever
>> used.
>
> Compacting the vector would also be possible, and I'm not sure it will
> be too expensive, since memcpy is quite fast on modern machines.
>
> All of this is not very important, except that we are talking about
> simplifications of FOR_EACH_MARKER macro, so if any of this
> facilitates a simpler macro without hampering performance, I'd suggest
> to consider it seriously.

(Just to mention an important aspect to keep in mind:

Some iteration over markers in master are for adjusting marker
positions, and these positions are held in the marker objects
themselves. These loops touch memory memory "all over the place".

In scratch/text-index, the marker positions are kept in the marker
vector, and adjusting positions can be done by accessing only the vector
from left to right. I think that is very CPU-cache-friendly. I would
expect that to be *much* faster than in master.)

Previous Next

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