Re^5: Is for(@$array_ref) construct optimized? YES!

[Aristotle]

It's the B::Deparse version, not the Perl version that matters here.

Makeshifts last the longest.

[Weasel]

I see, and this unsurprises me: newer B::Deparse understands additional typical constructs and resolves them. Isn't this bad? Don't know. I consider this improvement as not good, because before this day I used B::Deparse as a way to see into internal representation, and now I understand this is not 100% working.

Thank you for clarifying!

[Elian]

B::Deparse is supposed to get you what you fed into it, so the fact that it gets closer isn't a bad thing. If you want to see what's really happening, compile perl with -DDEBUGGING and watch the opcode trace some time.

[Weasel]

I see your point and completely agree with it.

You mean something similar to following log:

D:\Work\PerlCompile\perl@16925mgnu\lib\B>perl -MO=Terse -we "for(;;){}
+"
LISTOP (0x1be3c00) leave [1]
    OP (0x1a88ca4) enter
    COP (0x1be3c28) nextstate
    BINOP (0x1be3c64) leaveloop
        LOOP (0x1be3c8c) enterloop
        LISTOP (0x1be3cc0) lineseq
            OP (0x1be3d64) stub
            OP (0x1be3d44) unstack
            COP (0x1be3d08) nextstate
-e syntax OK

D:\Work\PerlCompile\perl@16925mgnu\lib\B>perl -MO=Terse -we "for(@$a){
+}"
Name "main::a" used only once: possible typo at -e line 1.
LISTOP (0x1a812d0) leave [1]
    OP (0x1a812b0) enter
    COP (0x1a81318) nextstate
    BINOP (0x1be3ad8) leaveloop
        LOOP (0x1be3bd4) enteriter
            OP (0x1be3c08) null [3]
            UNOP (0x1a88c78) null [141]
                OP (0x1a88c58) pushmark
                UNOP (0x1be3c70) rv2av [2]
                    UNOP (0x1be3c94) rv2sv
                        PADOP (0x1be3d74) gv  1
            PADOP (0x1a88ca0) gv  3
        UNOP (0x1be3b04) null
            LOGOP (0x1be3b28) and
                OP (0x1be3c28) iter
                LISTOP (0x1be3b50) lineseq
                    OP (0x1be3c50) stub
                    OP (0x1be3bb4) unstack
                    COP (0x1be3b78) nextstate
-e syntax OK

Id that's it, it succeeds even without -DDEBUGGING for me.

[Aristotle]

See my updated initial reply. All that's changed throughout history, as far as I can tell, is what values the various switches default to. It seems to have gone back and forth a couple times as time passed, at least I know old versions of the module used to expose the loop for($what;$it;$is) without extra switches passed.

Makeshifts last the longest.