Marvin Humphrey <[EMAIL PROTECTED]> writes: >On Apr 13, 2006, at 10:42 AM, Jeremy White wrote: > >> >>> There's sv_isa, which should be cheaper than sv_derived_from at >>> the expense of not testing inheritance relationships. I dunno if >>> the overload affects impacts the ability to use it. >> >> Yeah, it's cheaper - but not cheap enough:) I was playing around >> with trying to upgrade the SV, and stuffing data in the free slots, >> then using those slots to validate the type. Seemed to work for >> simple examples, but blew up when used in the real world - >> overloading makes things more complicated. >> >>> Moving stuff safely across the Perl/C boundary can be expensive. >>> Can you change the algorithm so that objects don't have to cross >>> so often? >> >> Not really, as the object is exposed to the end user.
Well you can still _allow_ that low level access (with the speed hit) but provide C-side constructs which "do more". For example Audio::Data allows user code to get/set individual sample values but also provides C methods/overload to work on a whole "track" If you do need speed, there is a trade-off between safety and speed. In the limit you don't _need_ to check anything at all. If perl is calling your XS it is because this "is" one of your objects. Nothing is faster than doing no check at all ;-) Downside is that if user corrupts the C-side structure, or "blesses" something else into your class or calls not-as method you get a segfault or other bad behaviour. Another approach is to have the C struct (or C++ object) associated with the perl object via "MAGIC". I think geting the C pointer via mg_ptr is slightly faster than sv_isa. > >Maybe you could do something insane and heroic, like keep a registry >of pointer addresses that represent qualified objects. Something >like what David Golden does with Class::InsideOut to provide thread >safety. Add each object to the registry when it is created, delete >it when it's DESTROYed. It would require a lot of code, but I'll bet >it would be faster than sv_derived_from. How desperate are you? But probably akin to sv_isa and subject to same kind of restrictions > >Marvin Humphrey >Rectangular Research >http://www.rectangular.com/
