Simon Cozens wrote:
> Currently, SvPVX(foo) requires one lookup
No lookups at all -- SvPVX(foo) is just a pointer offset, i.e. an add.
> with a vtable, it would necessitate two, (One to find the functino in "foo",
> and then the functino must find the data in "foo")
It would probably work something like
foo->vtbl[op](foo)
That's 2 adds, a lookup and a function call.
If vtbl is the first member in foo, then we can expect the compiler
to optimize away the vtbl offset calculation.
> Isn't this going to really, really hurt?
Well, with SvPVX(foo) you have to know a lot about the SV * already --
generally you have to check its type. Using the vtbl approach, you don't
check types because the vtbl encodes the right operation for the type.
Also, SvPVX doesn't *do* anything. There are a whole lot of function
calls surrounding SvPVX that do stuff. When you talk about how expensive
vtbls are you need to balance the cost of the vtbl against the cost of
whatever it replaces. It's not fair to measure against SvPVX because
the vtbl replaces a lot more than that.
Internal to a type, i.e. in a type's method, the SvPVX equivalent will
be as fast as Perl 5 because the method will use the type's internal
storage format.
- Ken
