in reply to Why doesn't perl optimize this?

Perl doesn't know whether you are going to use @a again in your first example. It's true that you don't use it, but the reference count doesn't actually go to zero until the end of the block, which comes after the [ @a ] construct.

But that is really beside the point: square brackets convert a list into an array ref. \@a, on the other hand, creates a reference to an array. Lists are not arrays.

Replies are listed 'Best First'.
Re^2: Why doesn't perl optimize this?
by LanX (Saint) on Jun 04, 2013 at 02:04 UTC
    Agreed!

    Maybe clearer: [@a] creates the ref to a copy (and copying is expensive) while \@a is the ref to the original array (no costs!).

    Cheers Rolf

    ( addicted to the Perl Programming Language)

      I know the difference. My question was not about the difference, it was about why the difference is not optimized away in cases like the one I cited.
        You seem to believe in magical powers of static code analysis in a dynamic language.

        plz tell me

        sub func { my ($code,@a) = @_; my $b = [@a]; eval $code; return $b; }

        How is the compiler supposed to know that '@a' can be destroyed w/o knowing what happens in '$code' at runtime?

        Cheers Rolf

        ( addicted to the Perl Programming Language)

Re^2: Why doesn't perl optimize this?
by nbtrap (Sexton) on Jun 04, 2013 at 02:02 UTC
    Yes, perl doesn't know, else it wouldn't copy the array. But my question is _why_ doesn't it know? Unless I'm mistaken, there's enough information in the code to know that @a will not be used again--even at compile time. This seems like a trivial optimization to me, but as I say, perhaps I'm overlooking something.

      nbtrap:

      All tasks are simple ... if you're not the one doing the work. Sure, there's enough information for perl to do the optimization you suggest. In fact, there may be enough information for it to simplify the code to:

      say time; say time; say time;

      However, code optimization is harder than it looks[1]. Notice that both say and time are calls to other code, which could possibly change @a. Not in this case, obviously[3][5][6], but for perl to know that a priori, it would have to track whether or not @a was possibly aliased to another glob. Using static analysis, that could be determined, except that perl has features that may make static analysis intractable or impossible.

      Disclaimer: I know nothing substantial about the internals of perl. I wrote a compiler some years ago, and spent a little (very little) time trying to put in some optimization. It was shortly after reading the Dragon book[2] . When you read the book and start imagining the data structures and algorithms you need to build it gives you a good appreciation of the problem.

      It's easy to go down rabbit-holes, too. How much time should it work on optimizing the code? If there are easy optimizations with big payoffs, then it's a no brainer. But after a while, you'll start running into diminishing returns. If you spend too much time on the optimization phase, then you can lose more time than you save.

      Notes;

      1. If it were easy, the code we write wouldn't need optimization, would it?
      2. The first edition, as the second didn't exist yet. It's a fascinating read, you should pick it up if you're interested in language construction and/or design!
      3. To us humans[4], anyway.
      4. Yes, the phrasing might be odd, considering my moniker.
      5. I don't really feel like renumbering these notes.
      6. I was wondering whether superscripts would stack, now I know.
      7. With silly notes...

      ...roboticus

      When you don't get enough sleep for an extended period of time, your posts can come off as a bunch of stream-of-consciousness blather[7].

      What if @a is tied? What if it has other magic attached? You and I both know it almost never does, but the cost of detecting those cases is substantial.

      Personally, I do prefer that it does not know. Any attempt to make a program smarter than the user, turns this program into monster prone to errors and hard to control. There must be a balance between "smartness" and "complexity". After all we, people, also should use our brains :)