develooper Front page | perl.perl5.porters | Postings from June 2013

Idly musing about vtables for hashes

Thread Next
Steffen Mueller
June 24, 2013 17:00
Idly musing about vtables for hashes
Message ID:

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.


[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 Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About