Kevin Ryde <user42 zip com au> writes:
Florian Ragwitz <rafl debian org> writes:+void +gperl_attach_mg (SV * sv, void * ptr) +{ + sv_magicext (sv, NULL, PERL_MAGIC_ext, &gperl_mg_vtbl, + (const char *)ptr, 0);I suppose the alternative to magic would be a pointer->pointer hash table would it? Would that be slower than hanging it in the magic list?
That'd certainly be possible. A good ptable implementation doesn't have to be a whole lot slower than using magic, but there certainly is more overhead. However, being horrible and entirely ignoring a well-defined extension point in the perl internals for no reason would seem like a downside. GObject used to use magic for associating pointers with scalars for ages, and I think that's the right thing to do. This patch set merely changes some implementation details of that.
Or on the other hand does the magic mean a check in there for all hash operations on objects?
There's no significant performance impact in using this kind of magic. We don't use any magic vtbl methods. We didn't because we didn't have an MGVTBL until this patch set, and with these patches we have an MGVTBL with nothing but NUL methods. Also, to influence things like hash operations on the underlying hash of an object we'd have to use uvar magic - we didn't ever do that, and this patch doesn't change anything about that either. It's still just plain PERL_MAGIC_ext.
Attachment:
pgpl9Wkxp4wx9.pgp
Description: PGP signature