bug#68244: hash-table improvements

[Mattias Engdegård]

8 feb. 2024 kl. 18.49 skrev Stefan Monnier <monnier@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.