Re: [PATCH 1/2] Allow for more than one PERL_MAGIC_ext magic

Kevin Ryde <user42 zip com au> writes:

Florian Ragwitz <rafl debian org> writes:

+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

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

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

Attachment: pgpl9Wkxp4wx9.pgp
Description: PGP signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]