Re: Efficient HV fetches without recomputing the key hash

On Wed, May 13, 2026 at 06:42:52PM +0100, Paul "LeoNerd" Evans wrote:
> The HV API is a bit of a mess of functions.

It anyone's going to give serious effort to modifying/adding to the HV
API, you might want to bear in mind that 12 years ago I informally
reserved an SV flag bit to allow for HV vtables, although I never got any
further.

The idea was that all the HV API functions (hv_fetch, hv_common etc etc)
would first check whether the HV had been flagged, and if so, call the
relevant vtable function instead. (The pointer to the HV's vtable would
possibly be stored in the aux struct, or maybe be a field in every HV).

This would have two benefits.

First, it would mean that a bunch of special-case code (e.g.
DYNAMIC_ENV_FETCH, ENV_IS_CASELESS, HV_DISABLE_UVAR_XKEY) could be removed
from the body of hv_common() etc. Instead, e.g. %ENV would have its own
vtable and handle any special-casing. Possibly tied hashes would also be
implemented by a vtable. Presumably there would be some mechanism for the
vtable method to fall back to the standard code, e.g; a flag to
hv_common() indicating 'ignore the vtable flag'.

Second, it would allow custom hash types: e.g. ones with a fixed set of
keys (such as objects) which could be stored as a simple array; or
caseless hashes; or ordered hashes; etc etc.

I never got anywhere beyond reserving the flag bit in sv.h (it's a use of
SVf_FAKE), and in particular never fully thought through the implications
of whether such a scheme was in fact viable.

But one thing that *did* occur to me at the time  was that the vtable
entries would have to be decided (and once decided, would be hard to
change). And it wasn't clear to me whether the vtable should just have
method pointers for the low-level hv_common() etc, or for all the
high-level hv_fetch(), hv_fetch_ent() etc, or for both.

I'm not suggesting that any improvement to the HV API must first include a
vtable mechanism; I'm merely mentioning it as it might influence any
further API design, even if vtables are left for another day.

PS: I don't know whether everyone is aware, but hv_common() isn't actually
API; its just the common underlying function which implements the bodies
of hv_fetch(), hv_store_ent() etc. It is used by just a handful of XS
distros, so we shouldn't rule out the possibility of changiing the
signature of hv_common().