In perl.git, the branch smueller/hash_vtable has been created <http://perl5.git.perl.org/perl.git/commitdiff/e854d9268d27d3194e7079943a767c4d0eba4cab?hp=0000000000000000000000000000000000000000>
at e854d9268d27d3194e7079943a767c4d0eba4cab (commit) - Log ----------------------------------------------------------------- commit e854d9268d27d3194e7079943a767c4d0eba4cab Author: Steffen Mueller <smuel...@cpan.org> Date: Tue Jan 24 10:48:06 2017 +0100 Proof of principle hash vtables This is a very partial implementation of having pluggable hashes by (optionally) having magic-alike vtables which make all top level hash operations pluggable. At this point, this has all sorts of objectionable shortcuts. It also means slowing down all operations by at least and extra compare+branch. It also only does this for deletes right now because I'm just dabbling. So in summary, this isn't much at all. The reason why I'm playing with this is that if one were able to specialize hash implementations (eg. perfect hashes or scanning small lists for low-number-of-keys objects, having actual sets for huge sets, having more compact "string only" (ie. no SV overhead) tables, etc etc), I'd expect that one could gain a bunch. Ultimately, this sort of thing is hindered by a great deal of things such as the complete insanity of the hash API (way too many ways to do things), the structure of the code (it's all shims to the same common function - in an attempt to reduce code duplication), and the horror that is MAGIC support. It's also decidedly hindered by my understanding of the intricacies of the code base. This doesn't solve the language design issue of how one would actually make this accessible to Perl users. It'd be reasonably easy to have a new keyword that takes an additional first parameter which indicates the hash storage type (presumably as a constant string which can be converted to a vtable at compile time using some kind of global lookup). In terms of execution, this could generate either an OP that is similar to pp_anonhash but has the type info on the stack, or it could literally generate a pp_anonhash which abuses its op_targ as a way to store the vtable pointer (PADOFFSET is an IV or UV which are big enough to hold a pointer, but yuck.). So I'm throwing this out there in case somebody (which includes my future self) finds this intriguing enough to try to pursue further. Right now, this commit includes a small change that redefines newHV to ALWAYS assign a vtable (instead of defaulting to NULL, which falls through to the normal hash implementation). It also ships a (partial) vtable implementation which is meant to behave exactly the same way as the normal implementation. This is to test that this whole scheme actually work. As I was saying, right now in this commit, newHV is hardwired to always set this "mock" vtable for testing. ----------------------------------------------------------------------- -- Perl5 Master Repository