Update: just saw ferreira's response; no, those don't work. They will try to call an undefined sub CORE::uc, not the builtin.

The preliminary results seem to indicate that a lot of the additional overhead is coming from the subroutine call when using autobox vs when using the CORE:: routines directly.

Actually, I would suspect that autobox's overhead is more likely coming from a combination of calling something as a method (which tends to be slower then subs, and certainly much slower than builtins) and the overhead of having to search the {SCALAR,ARRAY,HASH}:: namespace(s) for an applicable method.

Certainly the additional call levels are playing a part, but in more real-world usage of autobox (which wasn't just simple uses of CORE:: subs) I would suspect it would be much less relevant.

Certainly the additional call levels are playing a part, but in more real-world usage of autobox (which wasn't just simple uses of CORE:: subs) I would suspect it would be much less relevant.

Thanks stvn. I whole-heartedly agree with you on this point. I would like to at least optimize the core operations if possible (read easy). I feel it's something that others might also be interested in as far as lowering the entry point/barrier to using autobox speed-wise so we can get on with the more interesting uses.

I'm open to solutions that sub-class and/or hack the Perl portion of autobox and maybe even the XS part if chocolateboy is listening ;)

Of course, if it can be incontrovertibly shown that there is no optimizations to be had, then thanks and nevermind :)

I feel it's something that others might also be interested in as far as lowering the entry point/barrier to using autobox speed-wise so we can get on with the more interesting uses.

Well, as far as the speed is concerned, you can't get rid of the method calling overhead, but it might be possible to improve the method lookup through some creative caching. However, Perl is such a dynamic language, that you would have to be careful about this so that people can still get away with dirty hacks like adding to the SCALAR, ARRAY, HASH, etc. symbol tables. There is an XS accessible variable that tells you when someone has messed with the symbol tables, but IIRC it is a global thing and not per-package, but that could still be very useful. You could also look into handling some of the builtins at the XS level, though I have no idea if that would help or not.

Now as for the "more interesting uses" bit. While there are many cool things that you can do with autobox, it has some serious limits.

You cannot subclass and extend the "built in" classes (such as ARRAY and HASH) and get ARRAY and HASH like behavior (as you will be able to do in Perl 6). This is because the operators associated with hash and array access are not overloadable, so they can't be assocaited with your ARRAY and HASH packages. You would basically be stuck with $array->[0] always working in the same way, but $array->push(1) could have a different extended behavior. And I tend to doubt that autobox would work well with tie, so that couldn't help.

The next issue that I found with autobox is that all your hashes and arrays must be references (despite what the POD docs seem to indicate). While this is not bad if you are always doing method calls, it tends to make more idiomatic Perl kinda ugly since you must constantly de-reference and en-reference things in order to maintin the autobox-ness.

And then the last problem I have with it is that the pragma is not lexically scoped. The last time I talked to chocolateboy, he mentioned that he wanted to make it lexical once the lexical pragma patch is solid in the core, but this is still fairly bleedding edge at this point I think. Not being lexical means that everyone who wants to take advantage of your autoboxing needs to have use autobox within their package/file scope, which can get quite invasive. Of course you could also argue that this is a good thing because it keeps the magic contained and makes it less likely that autobox will create unintended things to happen deep within someone else's code.

I'm open to solutions that sub-class and/or hack the Perl portion of autobox and maybe even the XS part if chocolateboy is listening ;)

I dont think chocolateboy hangs out here, but I have discussed autobox with him through email (you can get the address from his CPAN directory) a few times and we was very helpful and informative.

-stvn

I don't know the source code of autobox, but as it is a non-standard module, things like $s.uc will probably be slower than uc $s always. But if the additional overhead comes from subroutine call, you can try something like:

BEGIN { *SCALAR::uc = \&CORE::uc }
[download]

sub SCALAR::uc { CORE::uc($_[0]); }
[download]

sub SCALAR::uc { goto &CORE::uc; }
[download]

(The BEGIN is important here to make it behave as a compile-time function declaration.)

If it works, you will have less one frame in the call stack, which may or may not speed things up. This suggestion is untested and may not work: There is some weirdness associated to the core functions that don't behave identically to the ordinary subs.

You can't take references to CORE:: functions and goto() is slower than just leaving the call frame on the stack.

⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊