Front page | perl.perl5.porters |
Postings from June 2013
All,
I've been thinking about what it takes to do vtables for hashes a bit
and chatting with Yves about it. At face value, this doesn't sound too
hard and the potential benefit of having multiple hash-like structure
implementations that can be swapped on a per-instance basis seems like a
real win, for example, to tighten up the size of objects.
To do an early prototype, mangling all the current hash interfacing code
to put in a vtable abstraction layer is probably quite doable[1]. Bits
that make me really scratch my head are:
- Caching of hash values. If we swap the hash implementation, the actual
value computed on a key string is at least going to change if not
invalidated altogether (eg. in the case of masquerading a tree as a
hash). This flies in the case of all places where we cache hash values
such as $hash{foo}. Since the container is now polymorphic, caching is
out the window. This isn't just a performance issue, but actually makes
me wonder how that could even be hacked in at all for an experiment.
- The global string table. Clearly, alternate hash implementations would
have to opt in to using it in the first place, but they at least need to
be able to do so fundamentally.
- HE* and friends are part of the API right now, but are really tied to
the underlying implementation.
I am quite aware that this isn't going to be a complete list of
downfalls. So I'd like field some feedback both to hear whether and if
so how these could possibly be worked around and which problems I'm
missing altogether.
--Steffen
[1] As a first stab, and for experimentation/compatibility, the current
hash API functions could be renamed from hv_foo to hv_foo_internal. Then
we create shim functions following the tentative vtable API that invoke
them appropriately. Then we create shim functions using the old hv_foo
names that follow the old API behaviour and implement those on top of
the vtable API. That'd be kind of slow and, depending on the similarity
of the current and future APIs, kind of yucky to implement, but it'd
most certainly be feasible to experiment with.
Thread Next