[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#68244: hash-table improvements
From: |
Stefan Monnier |
Subject: |
bug#68244: hash-table improvements |
Date: |
Thu, 08 Feb 2024 09:19:43 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
> 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
- bug#68244: hash-table improvements, Mattias Engdegård, 2024/02/08
- bug#68244: hash-table improvements,
Stefan Monnier <=
- bug#68244: hash-table improvements, Gerd Möllmann, 2024/02/08
- bug#68244: hash-table improvements, Mattias Engdegård, 2024/02/08
- bug#68244: hash-table improvements, Stefan Monnier, 2024/02/08
- bug#68244: hash-table improvements, Mattias Engdegård, 2024/02/08
- bug#68244: hash-table improvements, Stefan Monnier, 2024/02/08
- bug#68244: hash-table improvements, Mattias Engdegård, 2024/02/12
- bug#68244: hash-table improvements, Stefan Monnier, 2024/02/12
- bug#68244: hash-table improvements, Gerd Möllmann, 2024/02/13
- bug#68244: hash-table improvements, Mattias Engdegård, 2024/02/13
- bug#68244: hash-table improvements, Gerd Möllmann, 2024/02/13