On Fri, 3 Dec 2004 21:25:39 -0800, Larry Wall <[EMAIL PROTECTED]> wrote:

On Sat, Dec 04, 2004 at 06:31:35AM +0300, Alexey Trofimenko wrote:
:
:   for 1..10_000_000 {
:      my ($a,$b,$c) = ...
:      ...
:   }
:
: vs.
:
:   for 1..10_000_000 {
:      state ($a,$b,$c) = ...
:      ...
:   }
:
: latter looks like it would run faster, because no reallocation envolved
: here.

Er, how did you try a state variable in Perl 5?  It doesn't have state
variables...

I've emulated state vars like this: instead of for (...) { my $a = ...; ... }

i've written:

  { my $a;
    for (...) {
       $a = ...;
       ...
    }
  }

I think, effect is the same, (of course only if state vars declared at the top of the block)
(second variant IS faster in perl5. slightly:)
perl> timeit { my $a; for (1..10_000_000) { $a=10 } }
3.149s
perl> timeit { for (1..10_000_000) { my $a=10 } }
4.709s
)



P.S. btw, what about

  my @rray;
  # i'm starting to like that "sigil is a part of name" idea :)
  for 1..10 {
     {
       push @rray, \( state $calar )
     }
  }

  say @rray[0] == @rray[1]

what is the scope of state vars exactly? Common sense tells me that it should be exactly the same as i've shown in second snippet above.. and latter snippet would say undef.. so C<state> is just a syntactic sugar for C<my>, which also allow us to remove redundant outer block. is it?

P.P.S. ah, offtopic. I've forgot, are bare self executing blocks outlawed now? we have an ambiguity otherwise:
sub test {
...
{ #some bare block
...
}
}


looks like test() could return that block as closure in scalar context, but would execute it immediately in void. wow:)
I should reread apocalypses, definitely..



Perl 5 already stores all the lexicals in the pad for the entire
subroutine.  There is no separate pad for the inside of the loop.
Any differences in performance would be related to the actual
reinitialization of the lexical, not allocation.

hmm.. looks like heavy magic is involved here. Because perl5 makes a feeling that every _block_ has it's own lexical pad. so, does it mean that my $vars deallocated only on exit from surrounding subroutine, not from nearest surrounding block? my experience show opposite, but I could be wrong..
(or I just misunderstood conception of lexical pads)

Reply via email to