GNU bug report logs - #68244
hash-table improvements

Previous Next

Full log

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

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
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: Mon, 12 Feb 2024 13:16:44 +0100

8 feb. 2024 kl. 18.49 skrev Stefan Monnier <monnier <at> iro.umontreal.ca>:

>> And you are right about the need for vector compatibility, just discovered
>> that the hard way.
> 
> Welcome to the club :-)

And to show that I'm repeating all your mistakes and ignoring your hard-won wisdom, I made a patch for PVEC_OBARRAY.

* It does give a nice speed-up, not only in microbenchmarks. Relint on the Emacs directory tree sees a speed-up of 5 % which is not bad considering how much work that code does.

* Contrary to your suggestion I went with an entirely new type, which means that:

- obarray objects grow automatically and use the same faster hashing (Knuth) as hash tables
- `obarrayp` is now true for both obarray objects and vectors; `obarray-object-p` detects the new type only.
- `obarray-make` now produces an obarray object.
- All old built-in functions that take an obarray now accept both vectors and obarray objects
- New function `obarray-clear` to replace code that filled vectors with 0

* Compatibility with existing code is excellent except for some places that used `obarray-make` but then assumed the result to be vectors (using `vectorp` instead of `obarrayp` etc).

Your suggestion to represent obarrays as a single-element vector containing an actual object (PVEC_OBARRAY or a hash table) would kind of help here but it still seems like a half-measure and perpetuates some problems that we would like to avoid with a new type.

Maybe a different kind of compromise would be better: `obarray-make` is kept unchanged as make-vector (but deprecated), and a new `make-obarray` (for example) creates the new objects.

Oh, and there is a small glitch in the existing code: when a symbol is uninterned, its status is set to SYMBOL_UNINTERNED, but if its containing obarray is GCed away or manually cleared then this doesn't happen. This is probably not worth fixing but at least with PVEC_OBARRAY we could if we wanted to.

Previous Next

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