in reply to XS and overload

what do you want to do exactly?

Attaching overload magic to an object is atomatically done by sv_bless when an %OVERLOAD hash exist on the package (stash). That %OVERLOAD hash is initiallized by the overload module.

Initializing overloading in a module from XS can be done, but it is not a good idea as the implementation details for overloading modules could change. You should stick to using the overload module for that.

If what you want is to do some operation with perl data that could have overloaded methods, for operations that exist on the API, just look for the versions supporting magic. For the rest, for instance addition, you can use several aproaches:

The simplest and most compatible is probably to define some helper methods in Perl as...

sub add { $_[0] + $_[1] }
and call them back from XS.

Other way is to do as perl does internally. Look in its source for the tryAMAGIC set of macros (in pp.h) and emulate them in your XS code.

Replies are listed 'Best First'.
Re^2: XS and overload
by BrowserUk (Patriarch) on Apr 22, 2006 at 19:16 UTC

    Overloading is generally quite costly in performance terms. The standard answer to cutting overheads is to drop into XS. I've written an XS based class that for most operations acts like a normal array, but uses custom data structures underneath. It works quite well, but carries the inconvenience of object notation

    $obj->set( $n, $obj->get( $n ) + 1 ); instead of

    $ary[ $n ]++; for example.

    I'd like to reduce that inconvenience without paying too high a price for the syntactic sugar. Using the overload pragma to apply the overloading isn't a problem, but if it is possible to minimise the runtime overheads, that would be nice.

    I'm guessing that it would require a pretty full understanding of how and when the overloaded methods get looked up and called to optimise this. Having read the breif passage in perlxs on the OVERLOAD keyword; perused overload.pm; and generally looked around in the sources trying to understand how the pieces fit together I thought I'd ask for references to prior art before beating my brains out trying to understand this.


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
      if your data structure acts like an array, then you should be using the tie-array interface instead of overloading. The @{} overloading method is available but it is quite inefficient for most practical purposes.

      Well, actually, you can combine both overloading and tying. For instance, if you were developing a vector class:

      my $v = Vector->new(1..10); my $u = Vector->new(11..20); my $w = $u - $v; # overload my $e5 = $w->[5]; # tie
      There is nothing special about tie or overloading methods implemented in XS, you just have to give then the right names in the first case or register them as overload methods with the overload module (well, you will probably need to init the XS part from a BEGIN block, so that the methods are available when you do the use overload ...).

      About speed, not too long ago, I did some benchmarks for my Tie::Array::Packed module that implements a tie interface in pure XS for packed arrays, and found that it was around 15 times slower that perl native arrays (a pure perl implementation as provided by Tie::Array::PackedC is around 60 times slower than native arrays). The extra overhead is caused by the method dispatching and because on every call some SVs are created, copied and deallocated which are relatively expensive operations.

      On the other hand, comparing a tied array access or an overload operation to a method call, the performance should be quite similar. The only difference is that the tie/overload operation has to perform a magic lookup, something that only requires a few C operations.

        Thanks a lot. Tie::Array::Packed.xs will provide a great reference for what I am doing.

        I agree that the tie interface is the right way for all the array style operations, but there are a couple of extensions that go beyond what an array does, that would benefit from being overloaded.


        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.