GNU bug report logs - #68244
hash-table improvements

Previous Next

Full log

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 Dmitry Gutov <dmitry <at> gutov.dev>, Eli Zaretskii <eliz <at> gnu.org>,
 68244 <at> debbugs.gnu.org, Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: bug#68244: hash-table improvements
Date: Thu, 08 Feb 2024 09:19:43 -0500

> We should probably do the same for obarrays but those have more low-hanging
> fruit. I'll be back with some changes.

For me, the more important aspect of obarrays is that we should have
a separate obarray type (if it can share code with hash-table, that's
gravy).
Of course, we'd still have to *also* accept plain vectors, sadly.

Some years ago I proposed a patch which changed nothing to the
implementation of obarrays but introduced a new PVEC_OBARRAY which was
used instead of the "PVEC_VECTOR" (and given the variable size of
vectors *and* of those obarrays, these two tags were treated specially).
It suffered from the lack of bits in the word that holds the PVEC_*
tag and the vector's size limiting the size of obarrays to
too-small value.

But I think we can do something much simpler: vectors are accepted by
simply storing in the first field a reference to the actual obarray
object, so there's no need to play any games and/or share representation
between vectors and obarray.


        Stefan

Previous Next

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