in reply to Re^5: Does @{ } copy arrays?
in thread Does @{ } copy arrays?

Ie. Could not the application of magic to an array, and all the penalties that go with it, be deferred until it is used in an lvalue context?

ehm, that sounds like a very risky approach for tuning an edge case:

  DB<7> sub tst { $_[0]=3 }
 
  DB<8> @a=(1..10)
 
  DB<9> tst $#a
 
  DB<10> p @a
1234

[download]

personally I wouldn't care too much about the performance penalty, but the possible side-effects after forgetting that $#a is an lvalue and $_[0] is an alias, should be a reason enough to stick with scalar @a.

Cheers Rolf

Replies are listed 'Best First'.
Re^7: Does @{ } copy arrays?
by ikegami (Patriarch) on Oct 23, 2009 at 16:47 UTC

    I suppose there are cases where it's not immediately apparent to the parser if a given occurrence is an lvalue or rvalue?

    Perl is very much aware of which expressions should return something "M"odifiable. 

    $ perl -MO=Concise,-exec -e'  $x=$#a        ' 2>&1 | grep av2arylen
5  <1> av2arylen sK/1

$ perl -MO=Concise,-exec -e'  $#a=$x        ' 2>&1 | grep av2arylen
6  <1> av2arylen sKRM*/1

$ perl -MO=Concise,-exec -e'  foo($#a)      ' 2>&1 | grep av2arylen
6  <1> av2arylen sKM/1

$ perl -MO=Concise,-exec -e'  \$#a          ' 2>&1 | grep av2arylen
5  <1> av2arylen sKRM/1

$ perl -MO=Concise,-exec -e'  1 for $#a     ' 2>&1 | grep av2arylen
7  <1> av2arylen sKM/1

$ perl -MO=Concise,-exec -e'  1 for 0..$#a  ' 2>&1 | grep av2arylen
8  <1> av2arylen sK/1

    [download]
[reply]
[d/l]
      Can you provide the decoder ring for things like "sKRM*/1"?

      -QM
      --
      Quantum Mechanics: The dreams stuff is made of

[reply]

        B::Concise lists what opcode flag each letter represents. "M"odifiable is the relevant one here.

        Interesting tidbit:

        As an optimisation, lvalue subs weren't making arylen as Modifiable. 

        $ perl -MO=Concise,-exec,f -e'sub f :lvalue { $#a }' 2>&1 | grep av2ar
+ylen
4  <1> av2arylen sK/1

        [download]

        My patch relied on that flag, so it was buggy. The second patch I mentioned made lvalue subs mark arylen as Modifiable.

[reply]
[d/l]
Re^7: Does @{ } copy arrays?
by BrowserUk (Patriarch) on Oct 19, 2009 at 03:35 UTC
    an edge case

    Do you consider your example the common case? Relative to all the readonly uses of $#{}. Eg. 0 .. $#a; there are myriad others.

    dave_the_m suggested elsewhere that "$#{..} >= 0. As well as being uglier and more long winded than @{...},". Well, ditto scalar( @a ) - 1 versus $#a.

    But as so often in these cases, discussion is not entertained.

    On the basis of a very casual survey of code on my system and cpan, this "optimisation" is a space pessimisation if 9 cases out of 10 I looked at. In some cases, extremely.

    I'd love to see the evidence justifying the addition of tens of words to any array that you reference $#, in order to save "1 pointers-worth of memory just to store NULL" on those you don't. And that's before you consider the peformance effects.

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]
[select]
      as dave already said This could probably be optimised when pp_av2arylen is called in rvalue context.

      but my example shows that your suggestion Could not the application of magic to an array, and all the penalties that go with it, be deferred until it is used in an lvalue context? would effect manipulate code at long distance.

      And yes of course I consider my example to pass $#a as an argument an extremely common case.

      Cheers Rolf

[reply]

        I consider my example to pass $#a as an argument an extremely common case

        While I disagree about the commonness of passing $#a, there are options if it is deemed to be too slow.

        • $#a as an arg is an lvalue. Users can pass 0+$#a if they want the extra speed of an rvalue.

        • $#a as an arg is an rvalue. Users can use ${ \$#a } if they want an lvalue.

        • $#a as an arg is a delayed lvalue. I don't know if the mechanism can be extended to $#a, but hash element lookups are like this: 

          $ perl -le'\$h{k}; print exists($h{k})?1:0'
1

$ perl -le'sub{ $x=$_[0] }->($h{k}); print exists($h{k})?1:0'
0

$ perl -le'sub{ $_[0]=$x }->($h{k}); print exists($h{k})?1:0'
1

$ perl -le'sub{ $x=$_[0] }->(@h{k}); print exists($h{k})?1:0'
1

$ perl -le'sub{ $_[0]=$x }->(@h{k}); print exists($h{k})?1:0'
1

          [download]
[reply]
[d/l]
[select]
        And yes of course I consider my example to pass $#a as an argument an extremely common case.

        The validity of your example as a counter-argument relies not just upon passing $#a as an argument to a sub, but also on:

        1. Not assigning the arguments to named lexicals within the sub as is normal: 
          sub ...{
    my( ..., ... ) = @_;
}

          [download]
        2. And then, using the $_[...] alias as an lvalue.

        I bet you cannot find a single example of anyone doing this on cpan; or in any publically available piece of real code.

        Ergo, not a common case.

        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom