Making my methods 13x faster

Why not?

Ovid on 2007-10-10T07:54:22

OK, so the result looks impressive, but why not explain it? My knowledge of Perl internals is poor enough that I don't understand your code. I assume that you've disabled or skipped something which is ordinarily assumed, thus meaning that if someone wanted to use your technique, they'd have to accept certain constraints on their OO code?

Re:Why not?

jjore on 2007-10-10T14:35:32

It is the long rumored "my Dog $spot" optimization. If I know the type of my lexical at compile-time then I can substitute a custom opcode that implements my method call.

Also, I was tired. It was 1am.

Re:Why not?

Ovid on 2007-10-10T15:00:34

So this is something you could use to speed up AI::Prolog quite a bit, eh? Or is this global in effect and wouldn't allow folks to typed declarations? Is this only for kurila?

Re:Why not?

jjore on 2007-10-10T15:58:29

kurila? No. I've never used that. This runs on 5.8+. You could use this technique on anything where it is acceptable to bake in the object implementation. My guess is that this must be swappable for perl-code so that perl's sometimes incredible flexibility can be re-enabled. Using this optimization prevents things like duck typing from working.

Re:Why not?

Ovid on 2007-10-10T16:23:58

Sorry for the barrage of silly questions. Is this sort of like the Perl equivalent of declaring a class as "Final" (as Java does, for example) for performance benefit reasons?

Re:Why not?

jjore on 2007-10-10T17:07:15

I don't know about the performance implications of declaring a final class in Java.

Re:Why not?

Aristotle on 2007-10-10T18:27:17

Who cares about the performance in Java. The question is whether it is comparable with declaring a class final.

Re:Why not?

jjore on 2007-10-11T16:11:21

Yes, generally, it is. Though the declaration happens inside out. In Java I suppose you would declare this about your class and all your users would see the effect.

In Perl, with this change, you'd only see the effect if you'd compiled your class prior to compiling code that would later use it and also annotated your user code with

my Dog $pot

the syntax. This isn't strictly tied to the

my Dog $pot

syntax. The key is the annotation about a particular

$spot

being one that can be messed with. I could have also easily just inserted something like

BEGIN { this_is_it( '$pot' ) }

and used that to decide that the variable was of a class I could mess with.

It's up to you to decide how you want to communicate this information - I just think

my Dog $spot

is a reasonable annotation to do it with.

Re:Why not?

scrottie on 2007-10-10T18:42:52

Schweeeeet!!

I'll have to stare at it a while before I understand it, but I was gunning for something similar with my Code::Splice thingie. Rather than using those type declarations, I was just going to do static analysis of the code to find out where the optimization (in my case, of inlining method bodies) could safely be done. Huge program to be optimized, so an automatic approach was needed. I was fired before I could finish with only two weeks of brainpower on it. Gah. It seems like this would avoid the problem of not being able to inline code that did an explict 'return' or other similar control structures.

-scott

Re:Why not?

jjore on 2007-10-11T01:00:06

Sure, as long as your code can be rewritten in XS.